Hybrides Projektmanagement: Das Beste aus zwei Welten oder nur doppelte Bürokratie?

Grün im Sprintboard, rot im Meilensteinplan, gelb in Excel und in der Präsentation wieder alles entspannt: Wenn Projektstatus je nach Tool anders aussieht, ist nicht „das Team schlecht“ oder „agil gegen klassisch“ das Problem, sondern die fehlende Hybridarchitektur. Genau darüber sprechen wir, ganz praktisch und ohne Methodenkrieg: Wann ist hybrides Projektmanagement wirklich steuerbar und wann wird es nur doppelte Bürokratie mit modernem Etikett? 

Am Beispiel unseres Projekt Phönix aus dem Maschinenbau, ein digitales Service- und Ersatzteilportal mit fixem Messetermin, zeigen wir, wie mehrere Wahrheiten entstehen: Sprintfortschritt wirkt solide, externe Abhängigkeiten kippen Termine, Stakeholderwünsche wachsen im Chat und der Lenkungskreis bekommt eine Ampel, die wenig erklärt. Das kostet Zeit, Nerven und vor allem Entscheidungsfähigkeit. 

Du bekommst fünf klare Warnmuster, an denen du Methodenbrei erkennst: agile Rituale als Kontrolle, eine produktverantwortliche Rolle („Product Owner“) ohne Mandat, ein Backlog als Wunschcontainer, ein Lenkungskreis als Statuspublikum und ein Werkzeugzoo, der Unklarheit nur sauber dokumentiert. Danach bauen wir den Hybrid-Architektur-Check entlang der Felder Planen, Lernen, Entscheiden und Wahrheit und machen daraus einen Montags-Move für ein 60-Minuten-Klartext-Meeting. 

Wenn du Hybrid nicht als Ausrede, sondern als bewusstes Steuerungssystem nutzen willst, hör rein, hol dir den verlinkten One-Pager (https://stan.store/einfachprojekte/p/hybridarchitekturcheck), abonniere den Podcast, teile die Folge mit deinem Team und lass uns eine Bewertung da, damit mehr Projekte wieder eine klare, gemeinsame Wahrheit bekommen.

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

Wenn dich Klartext zu Projektarbeit interessiert, dann wirst du hier bestimmt fündig. Über diesen Link hast du Zugang zum aktuellen Podcast, zum kompletten Blog und zur Projektmanagement Toolbox:

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

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

https://www.1000freund.net/einfachprojekte/kompetenztest-projektleitung

Und wenn Du Fragen, gerne mit mir ins Gespräch kommen magst oder einfach noch mehr Klartext zu Projekten und erfolgreicher Zusammenarbeit suchst, findest Du hier genau das richtige: https://www.1000freund.net/3-wege-zum-klartext

Transcript

Wenn Statusfarben Sich Widersprechen

SPEAKER_02 0:00

Hey, ich habe mal eine Frage an dich. Was sagt es eigentlich über ein Projekt, wenn das Sprintboard grün ist, der Meilensteinplan rot, die Excel-Liste gelb und die PowerPoint-Ampel wieder grün? Und übrigens der Chat seit drei Tagen brennt. Was sagt es über ein Projekt, wenn das Team sagt, wir sind im Sprint gut unterwegs, die Projektleitung sagt, wir verlieren den Termin, das PMO sagt, uns fehlt der aktuelle Status und der Lenkungskreis sagt, warum erfahren wir das alles erst jetzt? Und was sagt es über ein Projekt, wenn alle Beteiligten behaupten, sie arbeiten hybrid, aber niemand weiß, welches System im Zweifel Recht hat. Und dann hast du wahrscheinlich nicht das Beste aus zwei Welten, dann hast du möglicherweise zwei Welten, die sich gegenseitig Arbeit machen, mit bunten Boards, mit gepflegten Meilensteinplänen, mit sehr ordentlichen Statusfolien und mit einer ziemlich teuren Unklarheit. Und genau darum geht es heute.

Hybrid Steuern Statt Methodenmix

SPEAKER_02 1:09

Es geht heute um hybrides Projektmanagement und zwar nicht als Methodenmodefolge und nicht als Scrum gegen Wasserfall, sondern als ganz praktische Frage, wann wird Hybrid wirklich steuerbar und wann wird daraus einfach doppelte Bürokratie mit modernem Etikett? Soll einfach dabei. Herzlich willkommen bei allen von Projekten. Mein Name ist Jan Thomas Freund und du kannst hier für deine Projekte. Strategien ansätze und Tipps. Vor allem in meinem Klangtext gesprochen. Und für dich, damit du direkt was damit anfangen kannst. Einfach dabei. Und damit wieder ganz herzlich willkommen hier bei Einfach Projekte. Und mich erlebst du, ja wie so häufig, im virtuellen Projektoffice. Und heute sprechen wir über ein Thema, das in vielen Organisationen ja schon echt vernünftig klingt. Und zwar hybrides Projektmanagement. Oder auch ganz häufig das Beste aus beiden Welten. Klassische Planung, damit Termine, Budget, Meilensteine und Governance sauber bleiben und agile Arbeitsweisen, damit Teams flexibel lernen, schnell reagieren und früh Ergebnisse zeigen können. Das klingt erstmal gut, sehr gut sogar und ganz ehrlich, das kann auch echt gut sein. Hybrid ist nicht falsch. Hybrid ist auch nicht irgendwie halbgar, weil Hybrid eben einfach Hybrid ist. Es kann sehr professionell sein, gerade im Mittelstand und gerade auch in technischen Organisationen übrigens. Überall dort, wo du einerseits Verbindlichkeit brauchst, weil es irgendwie um Kunden, Messen, Budgets, Abnahmen und so weiter geht, Verträge und regulatorische Anforderungen. Und wo du andererseits Lernen brauchst, weil Nutzerverhalten, Schnittstellen, Akzeptanz und neue Prozesse eben nicht am Anfang vollständig bekannt und durchschaubar sind. Also ganz wichtig, egal was jetzt gleich kommt, ich bin nicht gegen Hybrid. Überhaupt nicht. Aber ich bin sehr gegen den Satz, wir nehmen einfach das Beste aus beiden Welten. Übrigens, das habe ich früher auch gedacht, aber man kann sich auch mal korrigieren. Denn oft heißt das in der Praxis eben nicht, wir gestalten bewusst zwei Steuerungslogiken, sondern wir nehmen aus der klassischen Welt Kontrolle, Freigaben, Statusberichte, Meilensteine und so weiter. Und aus der agilen Welt nehmen wir Boards, Sprints, Dailies, Reviews und noch ein paar hübsche nette Rollennamen mit dazu. Und dann wundern wir uns, dass alle irgendwie im Verlauf müde werden und dass dann kein hybrides Projektmanagement zustande kommt, sondern das ist dann irgendwie ein klassisches Projekt mit agilem Anstrich. Und es sieht auf Folien mega aus, fühlt sich im Alltag aber oft an, wie irgendwie so wie so eine doppelte Bürokratie mit bunten Zetteln. So die typischen Haftnotizen, die man da so kleben kann. Und genau darüber möchte ich halt heute mal mit dir nachdenken. Also wieder mal kein Methoden-Podcast. Und ich erkläre auch nicht zum abermillionsten Mal, was Scrum ist. Und verteidige auch nicht das klassische Projektmanagement gegen agile Arbeitsweisen. Also kein Methodenkrieg, weil das Problem liegt ja nicht bei Scrum und auch übrigens nicht bei Meilenstein-Plan, sondern das Problem liegt in der Verbindung oder genauer gesagt in der nicht gestalteten Verbindung zwischen Lernen und Planen zum Beispiel. Oder zwischen Teamrealität und Managementsicht. Oder vielleicht auch zwischen operativer Wahrheit und Statusfolie. Und genau deshalb ist die zentrale Frage heute eben nicht, arbeiten wir agil oder klassisch. Die zentrale Frage ist eher, welche Teile unseres Projekts brauchen Planbarkeit, welche Teile brauchen Lernen und wie verbinden wir beides, ohne das System zu überlasten. Das klingt übrigens weniger sexy, als wie, wenn man sagen würde, das Beste aus beiden Welten. Aber es ist halt deutlich nützlicher und genau darum geht es heute, beziehungsweise darum soll es eigentlich immer gehen, was ist nützlicher. Du bekommst also in dieser Folge eine klare Diagnose, warum hybride Projekte oft doppelte Arbeit erzeugen. Und du bekommst von mir fünf Muster an die Hand, anhand derer du erkennst, ob euer Hybridmodell eher Methodenbrei als Architektur ist. Das Ganze packen wir dir in einen Hybrid-Architektur-Check. Und wie immer bekommst du noch von mir einen Montags-Move. Also was kannst du am Montag direkt umsetzen? Also es geht nicht um Perfektion, es geht nicht um wissenschaftlich hyper-hyper, sondern es geht einfach um Steuerbar. Und das ist ja schon mal viel wert. Und

Projekt Phönix Und Der Messe-Termin

SPEAKER_02 7:15

ja, wenn ich mit dir wieder mal in mein Beispielprojekt Phönix schaue, dann wäre das heute in einem mittelständischen Maschinenbauunternehmen angesiedelt, also kein Konzern mit eigenem Methodenzoo und so weiter und so fort, sondern solide gewachsenes Unternehmen, Maschinenbau, gute Produkte, top-Leute, starke Kundenbeziehungen, viele Experten, die ihr Geschäft verstehen. Und jetzt soll ein digitales Service- und Ersatzteilportal eingeführt werden. Die Idee ist gut. Und die Kunden sollen eben einfach Ersatzteile einfacher finden, Serviceanfragen sollen sauberer laufen, Technikerinnen sollen weniger Zeit in manuellen Abstimmungen verlieren und der Vertrieb möchte eben einfach digitale Kundenbildung. Bindung, nicht Bildung, sondern Bindung damit erreichen. Und für den Service könnte da noch bessere Transparenz rausspringen. Und die Geschäftsführung möchte einfach ein modernes Angebot. Und so hat man hier so eine Vielzahl an Ideen, wie es sein könnte. Übrigens, Marketing will natürlich auch was. Und deswegen muss man eben einfach schauen, wie können wir das Ganze gut umsetzen. Bei Phoenix gibt es übrigens auch einen fixen Zieltermin, weil das Portal soll bis zu einer Messe in der ersten Version stehen. Nicht perfekt, aber nachvollziehbar. So dass die Kunden ein bisschen damit arbeiten, in Anführungsstrichen können und spielen können. Das Ganze soll natürlich auch irgendwie sicher, stabil, datenschutzkonform, benutzerfreundlich und möglichst wartungsarm sein. Und auf dem Papier wird eben das Projekt hybrid aufgesetzt und das ist auch ganz vernünftig. Es gibt einen Meilenstein-Plan, weil es stehende Messe an, Budget, Lieferanten, Schnittstellen und so weiter. Muss alles geplant werden. Und es gibt ein agiles Team, weil man bei einem digitalen Portal eben nicht alles am Anfang wissen kann, was auch ganz natürlich ist. Also was weißt du häufig noch nicht? Wie suchen die Kunden wirklich? Welche Informationen brauchen sie? Welche Ersatzteilbilder helfen am meisten? Welche Datenqualität ist bei uns intern vorhanden? Und so weiter und so fort. Das lässt sich alles nicht im Kickoff sauber festhalten und deswegen ist es total gut, eben vielleicht nicht sozusagen in der klassischen Denke das Ganze zu starten, sondern man arbeitet in zweiwöchtigen Sprints. Es gibt ein Board, es gibt einen Backlog, es gibt einen Product Owner, Reviews und Dailies. Und auf der Teams, Team-Ebene sieht es erstmal auch gar nicht so schlecht aus. Die Sprints laufen, dass irgendwie so ein Prototyp entsteht, ein Login wird umgesetzt und erste Daten aus dem RP-System werden eingebunden. Und die Servicekollegen zum Beispiel, die schauen in ein Review und sagen, ja, das ist schon nah dran, aber so sucht kein Kunde nach diesem Teil. Das wissen wir ja, agile Sichtweise, wertvolle Erkenntnis. Der Vertrieb sagt, unsere Top-Kunden brauchen unbedingt eine Favoritenliste. Auch nachvollziehbar. Und übrigens, das Marketing sagt, für die Messe brauchen wir eine saubere, schönere Oberfläche. Nicht überraschend. Und dann kommen noch andere mit dazu, Controlling, Geschäftsführung mit absolut erwartbaren Ergänzungen und alles menschlich verständlich. Und ja, jetzt beginnt halt das hybride Elend. Weil das Team pflegt natürlich ganz brav sein Sprintboard und dort sieht vieles ganz ordentlich aus. Dort sieht vieles ganz ordentlich aus, weil Storys werden umgesetzt, Tasks werden geschlossen, in Review wird über sichtbare Fortschritte gesprochen und die Projektleitung pflegt parallel den Meilenstein. Doch es sieht halt dort weniger schön aus, weil irgendwie ein Schnittstellen Meilenstein ist gefährdet, die Datenqualität aus dem Ersatzteilkatalog ist schlechter als gedacht und ein externer Dienstleister braucht länger. Also typische Projektarbeit. Und deswegen werden Fortschritt riesigen Termine, Budget eben nochmal in eine andere Logik übersetzt, weil der Lenkungskreis bekommt ja eine PowerPoint. Nicht zu technisch, nicht zu detailliert, mit Ampel, auf jeden Fall natürlich mit Ampel, weil Lenkungskreis braucht Ampeln. Und der Fachbereich diskutiert noch parallel im Chat. Da entstehen dann übrigens auch Wünsche, Rückfragen, Entscheidungen, Halbsätze, Missverständnisse, also alles, was so in so einem Chat entsteht. Und ja, dann passiert halt folgendes. Es gibt eigentlich nicht mehr die eine Projektwahrheit. Es gibt mehrere. Im Board ist der Sprint erfolgreich. Im Meilenstein-Plan ist der Termin kritisch, der Excel-Status ist gelb und die PowerPoint ist irgendwie noch grün, weil den Lenkungskreis müssen wir auch nicht nervös machen. Und im Chat ist die Stimmung schon komplett abgeschmiert. Übrigens in der Kaffeeküche ist das Projekt sowieso schon längst in ein typisch IT-Projekt sozusagen abgeglitten. Das ist jetzt das Projekt Phoenix. Und übrigens nicht, weil dort schlechte Leute arbeiten oder die Projektleitung unfähig ist oder das Team keinen Bock hat und die Führung ist sogar auch nicht schuld. Sondern weil ein hybrides Projekt gestaltet wurde, ohne die Architektur des Hybriden sauber zu klären. Ein

Vier Fragen Für Klare Steuerung

SPEAKER_02 13:52

Projekt hat agile Rituale. Also dieses Projekt hat agile Rituale, so muss ich sagen. Es hat eine klassische Steuerung, es hat Governance, Tools, Statusformate, es hat Rollen, aber es hat eben keine klare Antwort auf die folgenden vier Fragen. Erstens, was wird geplant? Zweitens, was muss gelernt werden? Drittens, wer entscheidet im Konflikt? Und viertens, welches System gilt als Wahrheit? Du kennst den Spruch, möglicherweise, falls du schon ab und zu mal hier bei mir mit dem Podcast warst. Zu diesem System und die Wahrheit. Es geht ja immer um das bekannte Single Source of Truth. Also wo ist die Wahrheit sozusagen gehostet, könnte man sagen. Und wenn diese vier Fragen ungeklärt bleiben, bekommst du halt keine Steuerung. Du bekommst irgendwie doppelte Bürokratie, Pflege, du bekommst Diskussionen und auch doppelte oder vierfache Frustration. Die Projektleitung sitzt da wie immer zwischen den Stühlen und Team Management, PMO und alle anderen Beteiligten haben natürlich alle aus ihrer Sicht ein bisschen Recht. Und das ist halt das Gemeine an solchen Situationen. Es gibt nicht den einen Bösewicht, sondern es gibt ein System, in dem viele Beteiligte vernünftige Dinge tun und zusammen entsteht dann Unvernunft. Und das ist kein Vorwurf übrigens. Das ist reine Diagnose. Und die Diagnose an dieser Stelle lautet: Hybrid ist nicht das Problem, sondern zufälliges Hybrid ist das Problem. Ein hybrides Projekt ist nicht automatisch schlecht. Ein hybrides Projekt, das nur dadurch hybrid ist, dass verschiedene Bereiche ihre bevorzugten Arbeitsweisen nebeneinander durchsetzen, ist nicht professionell hybrid. Es ist irgendwie anders hybrid. Also die IT arbeitet agil, weil sie mit wechselnden Anforderungen umgehen muss. Verständlich und normal. Das Management steuert klassisch, weil Budget, Investitionslogik und Termine gebraucht werden. Auch klar. Wenn es ein PMO gibt, dann verlangt das PMO Standards, weil Vleichbarkeit notwendig ist. Da geht es nicht um super irgendwie alles zu beschreiben, sondern eben einfach, das PMO versucht ja, Dinge vergleichbar und dadurch steuerbarer zu machen. Der Einkauf muss in Verträgen denken, der Fachbereich denkt in den Wünschen, ist auch normal. Und das Team muss halt auch in Umsetzbarkeit denken. Übrigens, die Geschäftsführung hat ja auch noch so etwas ähnliches wie strategische Ziele. Und irgendwann nennen alle dieses Konglomerat Hybrid. Und das kann funktionieren, aber eben nicht automatisch. Und das funktioniert besonders dann nicht, wenn die Spannungen nicht offen geführt oder ausgetragen werden. Denn Hybrid bedeutet halt nicht, alle dürfen ihre Lieblingsmethode behalten. Und die Projektleitung baut daraus irgendwie ein Gesamtbild, sondern Hybrid bedeutet, wir entscheiden bewusst, welche Steuerungslogik für welchen Teil des Projekts gilt. Also planbare Teile werden geplant, unsichere Teile werden iterativ gelernt, darum geht es ja. Und Entscheidungsrechte werden geklärt, übrigens wieder so ein No-Brainer an der Stelle. Und das Reporting wird so aufgebaut, dass es die Steuerung unterstützt und nicht einfach nur ein Selbstzweck ist. Und ja, damit wird halt nicht nur Beschäftigung erzeugt. Und das klingt zwar total logisch, klingt sogar vielleicht auch einfach, ist es aber nicht. Weil es unbequeme Gespräche verdankt. Und zwar nicht nur im Team, sondern auch mit der Führung. Und zwar mit allen Beteiligten, also Sponsor, PMO. Natürlich auch mit den Fachbereichen, dem Lenkungskreis und so weiter. Also mit allen, die gern Flexibilität hätten, aber nicht ohne dass sich an Termin, Budget, Umfang oder Erwartung irgendwas bewegt. Und

Muster 1 Rituale Als Kontrolle

SPEAKER_02 18:18

jetzt kommen wir zu den fünf Mustern, an denen du erkennst, dass euer hybrides Projekt gerade in Richtung Methodenbreiki. Muster 1. Agile Rituale auf klassischer Kontrolllogik. Das ist so der Klassiker. Also das Team macht Dailies, aber eigentlich sind es irgendwie tägliche Rechtfertigungsrunden. Das Team macht Sprints, aber jeder Sprint wird behandelt wie ein kleiner Wasserfall mit Mini-Freigabe am Ende. Und es gibt Reviews, aber niemand nutzt sie, um Entscheidungen über Produkte, Nutzen und Scope zu treffen. Stattdessen ist eine Review eine Präsentation und man zeigt, was alle nicken. Und ein paar sagen, hey, super. Und andere sagen, können wir noch schnell irgendwie XYZ und danach geht alles wieder weiter wie vorher. Klingt mega modern, ist aber nur Status mit anderen Möbeln, könnte man sagen. Ein Daily ist nicht dazu da, das Management beruhigt schlafen zu lassen. Ein Daily ist dazu da, dass das Team seine Arbeit synchronisiert, Hindernisse sichtbar macht und den nächsten Schritt klärt. Und übrigens Daily heißt der Daily aus einem bestimmten Grund, weil es auch wieder was mit Rhythmus zu tun hat. Ein Review ist nicht dafür da, am Ende einer Iteration Applaus zu bekommen. Ein Review ist dazu da, anhand von echten Ergebnissen zu lernen und die nächsten Entscheidungen besser zu treffen. Also das Review darf auch mal schief gehen, in Anführungsstrichen, das ist ganz normal. Ein Backlog ist nicht einfach eine To-Do-Liste mit schickeren Namen. Es ist ein Entscheidungsinstrument. Und wenn du agile Rituale einführst, aber die dahinterliegende Logik entweder nicht verstehst oder nicht zulässt, dann bekommst du halt keine Agilität. Dann bekommst du allerhöchstens zusätzliche Meetings, und das ist jetzt nicht unbedingt ein Erfolgsfaktor. Also das Problem ist nicht das Daily. Sondern das Problem is, wenn das Daily zum Kontrollinstrument gemacht wird. Und der Sprint, der dann zwar gemacht wird, aber jede Erkenntnis als Planabweichung behandelt. And the Review ist übrigens auch nicht das Problem. Das Problem is, wenn niemand im Review entscheiden darf. Oder entscheidet. Ja, und dann ist das Review halt kein Lernmoment, sondern dann ist es irgendwie eine Vorführung. We gotta PowerPoint. And irgendwann kann das Team das dann super Fortschritt präsentieren, aber liefert eben nicht unbedingt Wert. And spätestens da ist es dann gefährlich, weil das sieht dann super professionell aus mit allem drums und trunns, but dahinter is eine ganz entscheidende Frage unbeantwortet. Und zwar, was haben wir gelernt und was ändern wir deshalb? When this Frage nicht erlaubt is, dann ist das Projekt halt nicht agil. Dann ist es irgendwie agil dekoriert, könnte man sagen.

Muster 2 Product Owner Ohne Mandat

SPEAKER_02 21:49

Übrigens, damit sind wir dann schon bei Muster 2. Product Owner ohne Macht. Und das ist eines der ganz schmerzhaften. Muster in hybriden Projekten, weil da wird jemand zum Product Owner gemacht. Häufig aus dem Fachbereich und manchmal aber auch aus der Stabsstelle raus. Und diese Person soll jetzt priorisieren. Klingt erstmal sinnvoll. Nur leider darf sie halt nicht wirklich irgendwas entscheiden. Sie darf irgendwie Backlog pflegen, Workshops moderieren, Anforderungen einsammeln, zwischen Bereichen vermitteln und im Review freundlich lächeln. Aber wenn es ernst wird, wenn also etwas raus muss, wenn ein Wunsch verschoben wird und wenn ein Bereich enttäuscht wird, wenn ein wichtiger Stakeholder nicht alles bekommt, dann wird es halt dünn. Dann heißt das, das können wir nicht alleine entscheiden, oder das muss die Geschäftsführung wissen, oder der Vertrieb ist strategisch wichtig oder irgendwas anderes Spannendes. Und in Summe ist das halt dann schon wieder ein Problem. Ein Product Owner ohne Mandat ist kein Priorisierer, sondern ist, keine Ahnung, der Vermittler fremder Wünsche. Er darf dokumentieren, was alle wollen, aber er darf nicht gestalten, was wirklich entsteht, was übrigens eigentlich die Rolle des Product Owners ist. Und dann wundern sich alle, dass das Backlog wächst und dass irgendwie nicht so richtig was vorangeht. Der Product Owner versucht eben jetzt in unserem Beispiel die erste Portalversion auf das Wesentliche zu fokussieren. Login, Ersatzteilsuche, Basisinformation, Serviceanfrage und so weiter und so fort. Und dann kommen halt andere mit dazu und wollen noch dies und das und jenes. Und wieder wie immer, nichts davon ist absurd, aber zusammen macht alles den Scope kaputt. Und dann kommt es halt jetzt darauf an, dass der Product Owner sagen darf, nein, nicht in diese Version. Oder dass er sagen darf, wenn das sein soll, muss was anderes raus. Oder das ist wichtig, aber nicht vor der Messe. Also solche Geschichten. Weil wenn er das alles nicht darf, dann ist Priorisierung, die eigentlich in der Rolle sein sollte, nur Theater. Dann ist es eine Rolle ohne Macht. Und Verantwortung ohne Spielraum ist halt Verantwortung mit angezogener Handbremse. Oder vielleicht auch im Leerlauf. Wer weiß das schon so genau. Das ist mega frustrierend. Nicht nur für den Product Owner, sondern natürlich auch fürs Team, für die Projektleitung. Und am Ende steht halt irgendwie was ganz Ungünstiges. Übrigens, da hilft auch kein weiteres Tool oder keine schönere Backlog-Ansicht und schon gar kein Zertifikat, da hilft nur Mandat. Ganz nüchtern. Also die Antwort auf die Frage: Wer darf was entscheiden? Was darf der Product Owner streichen? Welche Kriterien gelten dafür? Und wer schützt die Entscheidung gegen alle anderen? Was passiert, wenn ein Bereich versucht, die Priorisierung politisch zu umgehen? Ist auch noch so eine wichtige Frage. Klingt streng, ist es aber gar nicht, ist fair. Denn ohne diese Klarheit wird der Product Owner halt einfach nur verbrannt und das Projekt gleich mit. Drittes Muster kommt jetzt schon.

Muster 3 Bis 5 Backlog Kreis Tools

SPEAKER_02 25:44

Das Backlog wird zum Wunschcontainer. Ein gutes Backlog ist ein sehr nützliches Instrument. Es macht sichtbar was Mögliches, es sammelt Ideen, Arbeit wird strukturiert und Wert wird priorisiert. Alles gut, alles schön und es macht alles schön Transparenz. Ein schlechtes Backlog ist irgendwie sowas wie ein digitaler Müllplatz für alles, was irgendwann jemand wichtig fand. Und übrigens in hybriden Projekten passiert das ganz schnell. Warum? Weil klassische Erwartungen und agile Lernlogik aufeinandertreffen. Und auf der einen Seite gibt es eben einen fixen Termin, Budget, Meilenstein und Erwartungen und auf der anderen Seite gibt es halt Feedback, neue Erkenntnisse, neue Anforderungen, Nutzerreaktionen und technische Überraschungen. Wer hätte es gedacht? Und das ist wieder völlig normal und das ist nicht das Problem. Das Problem beginnt, wenn alles Neue ins Backlog kommt, aber nichts Altes rausgeht. Dann ist das Backlog irgendwie super höflich, weil es sagt nicht nein, es nimmt nichts raus, es lächelt immer nur und sortiert vielleicht noch ein bisschen. Und irgendwann ist es halt einfach nur eine Sammlung von irgendwas. Ein übervolles Backlog ist oft eine Sammlung von nicht ausgetragenen Konflikten. Weil Entscheidung, ja, etwas nicht zu tun, das hätte ja jemand enttäuschen können. Und Enttäuschung ist in vielen Organisationen oftmals noch viel schlimmer als Überlastung. Schade eigentlich. Also wird halt nicht entschieden, sondern es wird gesammelt, vertagt, auf später verschoben. Priorität wird anders vergeben und so weiter. Das sind alles so Klassiker. Und das Backlog wächst dann halt, der Termin bleibt, das Budget bleibt, die Kappa bleibt. Und das Projekt ist dann angeblich agile. Is it not? When sight and budget fix, muss scope bewegnis, and when scope fixed is, music and budget bewegly sein. When all this is fixed is, is this project not agile. And that might a bit zynisch klingen, aber nur weil die Realität sich an der Stelle auch nicht besonders charmant verhält. Also Backlog braucht Pflege, aber es braucht halt vor allem Konsequenz. Und nicht alles, was wichtig ist, ist dran und nicht alles, was sinnvoll ist, passt in die aktuelle Version. Und auch nicht jeder Wunsch darf kostenlos mit rein. Sondern man muss da eben einfach auch so ein bisschen schauen. Also lernen heißt ja, wir verändern unsere Entscheidungen auf Basis unserer Erkenntnisse. Und das ist halt der große Unterschied. Kommen wir schon zu Muster 4. Der Lenkungskreis wird zum Statuspublikum. Der Lenkungskreis soll lenken. Kleine Erinnerung an der Stelle. Und zwar nur für den Fall. In hybriden Projekten ist der Lenkungskreis besonders wichtig, weil Zielkonflikte schneller sichtbar werden. Also man braucht ihn noch mehr. Also zum Beispiel Konflikte können sein, mehr Scope, gleicher Termin, mehr Budget, weniger Funktionsumfang, mehr Qualität, höheres Risiko. Also Konflikte gibt es ganz, ganz viele. Und das sind halt keine Detailfragen, das sind Steuerungsfragen. Und diese Fragen gehören nicht irgendwie alle, also gehören nicht ins Team, sondern die Fragen müssen in einer anderen Runde geklärt werden. Und die Projektleitung kann häufig nicht alleine entscheiden, ob das Budget erhöht wird. Und der Lenkungskreis ist halt genau dafür da, um Zielkonflikte aufzulösen. Ist übrigens immer. Und das passiert halt oft, der Lenkungskreis bekommt irgendwie eine Statuspräsentation, Ampelmeilensteine, riesigen Budget und so weiter und so fort. Dann wird so ein bisschen Fragen gestellt, diskutiert und irgendjemand sagt, das nehmen wir nochmal mit oder bitte prüfen Sie die Option. Diese ganzen fluffigen Dinger. Und dann bleibt halt die Entscheidung offen und ein Lenkungskreis, der nicht entscheidet, der lenkt halt nicht. Der schaut einfach nur gepflegt zu. Und noch schlimmer, ist sozusagen der Veredlungsort der Unentschlossenheit. Unentschlossenheit mit Teilnehmerliste, könnte man sagen. Klingt hart, aber in vielen Projekten ist es halt genau der Punkt. Der Lenkungskreis wird zum Ort, an dem alle sehen, dass ein Problem existiert, aber nicht zum Ort, an dem ein Zielkonflikt entschieden wird. Das wird dann wieder irgendwo hinausgelagert, wo es gar nicht entschieden werden kann. Und dann, keine Ahnung, zur Projektleitung oder zum Team. Und das macht alles gar keinen Sinn, weil dann muss da irgendwie improvisiert werden, zehn Umwege gegangen werden und so weiter und so fort. Also wer muss entscheiden? Der Lenkungskreis. In einem guten hybriden Projekt ist der Lenkungskreis eben nicht das Publikum, sondern er ist Eskalations- und Entscheidungsinstanz für Spannungen. Und wodurch entstehen diese Spannungen in hybriden Projekten aus der Spannung von Planung und Lernen. Also klassisch und agil. Wir müssen übrigens auch nicht jedes Detail entscheiden, sondern der Lenkungskreis gibt halt einfach sozusagen Impulse bei Zielkonflikten oder entscheidet bei Zielkonflikten und nicht jedes Klein-Klein. Und darum geht es. Und das ist ein Stück weit eine andere Herangehensweise. Wir brauchen also vom Lenkungskreis Führung. Und das ist dann nützlich. Übrigens, jetzt kommen wir noch zum Muster Nummer 5. Zum Tool Zoo mit mehreren Wahrheiten. Auch toll. Und man könnte sagen, das ist fast so ein bisschen schwerpunkthaft in vielen Projekten, der Toolzo. Weil hybride Projekte sind erstaunlich oft gleichzeitig überdigitalisiert und unterklar. Überdigitalisiert und unterklar. Also das Team hat ein Board, dann gibt es, keine Ahnung, Jira, Trello, Planner, was auch immer. Die Projektleitung hat noch einen Meilenstein-Plan gebastelt, in MS Project oder vielleicht auch im Planner, vielleicht sogar in Excel. Und dann gibt es noch irgendwie ein Roadmap-Tool und das PMO macht noch irgendwas in Excel. Und dann gibt es vielleicht noch ein Projektmanagement-System, ein anderes mit dazu. Der Lenkungskreis kriegt ein schönes PowerPoint. Der Fachbereich kommuniziert in Teams oder Slack. Und wie gesagt, die Geschäftsführung kriegt dann noch eine Ampel. Der Dienstleister hat ein eigenes Ticketsystem. Und vielleicht gibt es dann auch noch irgendwo eine Datei, die heißt Final Final Neue Version 3.8. Alles Quatsch. Denn ohne die ist ein Projekt offenbar nicht vollständig. Das stimmt natürlich nicht. Das Problem ist nicht, dass es mehrere Tools gibt. Manchmal brauchst du unterschiedliche Sichten, alles vorhin. Eine operative Sicht, eine Steuerungssicht, eine Vergleichbarkeit und so weiter und so fort. Alles legitim. Das Problem entsteht, wenn nicht klar ist, wie diese Sichten zusammenhängen und sich gegenseitig beeinflussen. Dann pflegen Menschen dieselbe Information mehrfach. Oder schlimmer, sie pflegen ähnliche Informationen mit leicht unterschiedlichen Bedeutungen. Im Board steht zum Beispiel Story abgeschlossen, in Meilenstein steht Meilenstein gefährdet. Und übrigens im Exo-Report steht Fortschritt 70%. Und da ist dann halt die Frage, welche Wahrheit geht. Und das ist jetzt keine philosophische Frage. Sondern im Projekt ist das eine Steuerungsfrage. Wenn das Board grün ist, aber der Meilensteinplan rot, was bedeutet das? Vielleicht bedeutet es ja, dass das Team erledigt seine Sprintarbeit erst, aber die Sprintarbeit reicht nicht, um den externen Meilenstein zu halten. Vielleicht bedeutet es aber auch, dass der Meilensteinplan veraltet ist. Oder die Storys zu klein geschnitten. Und die zeigen irgendwie Aktivität, aber keine Lieferfähigkeit. Oder vielleicht auch eine Abhängigkeit, die das Team von außen blockiert. Also ganz, ganz viele Möglichkeiten. Kann alles sein. Aber solange niemand diese Übersetzung klärt, entsteht halt Unsicherheit. Und Unsicherheit erzeugt Zusatzarbeit. Dann fragen ganz viele nach. Die Projektleitung baut eine Statusfolie, das Team klärt nochmal den Zwischenstand, der Sponsor ruft an und will es nochmal wissen. Ein Sondertermin wird angesetzt und so weiter und so fort. Menschen verbringen halt ganz viele Menschen Zeit damit, den Zustand des Projekts zu erklären, statt den Zustand des Projekts zu verbessern. Vielleicht kennst du das aus deiner eigenen Welt. Das ist halt der Preis mehrer Wahrheiten. Also mehr Tools erzeugen keine Wahrheit. Sie erzeugen nur gepflegte Unklarheit, wenn die Governance dahinter fehlt. Also ein Tool in sich ist kein Wahrheitsanker. Es ist wie ein Behälter. Die Wahrheit entsteht durch klare Regeln. Wer pflegt was? Welche Information ist operativ verbindlich? Welche Information ist Managementsicht? Welche Information ist entscheidungsrelevant und so weiter und so fort. Und dann hast du eben nicht irgendwie Digitalisierung und du hast digitale Mehrfachbuchhaltung. Das ist vielleicht manchmal sogar notwendig, aber für eine Übergangszeit. Und dann muss es irgendwann bewusst entschieden werden, welches Tool ist unser Leading-Tool. Ein Statusbericht hilft niemandem zu entscheiden, er ist kein Steuerungsinstrument, er ist Lesestoff. Und Projekte brauchen nicht mehr Lesestoff, sie brauchen Klarheit. Und deswegen ist es ganz wichtig, oder andersrum, wir gucken nochmal kurz auf das Phoenix-Projekt. Stell dir vor, das wäre jetzt seit sechs Wochen unterwegs. Das Team ist müde, die Projektleitung genervt. Product Owner fühlt sich hin und her gerissen und der Sponsor sagt, ich will keine Überraschung. Und alle irgendwie sind sich einig, so kann es nicht weitergehen. Klassischer Reflex wäre jetzt, wir brauchen bessere Disziplin im Reporting oder das Team muss das Board sauberer pflegen oder der Product Owner muss konsequenter priorisieren und so weiter und so fort. Aber das ist alles viel zu klein gedacht.

Systemretro Und Eine Projektwahrheit

SPEAKER_02 37:42

Die bessere Intervention ist eine Systemretro. Also nicht eine Teamretro, sondern ein Systemretro. Deswegen, es wird nicht gefragt, was lief im Sprint gut und was lief schlecht und was nehmen wir uns vor, sondern funktioniert unser Hybridmodell, mit dem wir gerade arbeiten, überhaupt? Und das ist eine ganz andere Frage. Sie gehört nicht nur ins Team, sondern in diesem Termin gehören Projektleiter und Product Owner, Sponsor und möglicherweise noch andere Leute mit dazu. Vielleicht sind das 24 Menschen. Hoffentlich nicht so viel. Aber eben die Rollen, die das System prägen, und dann stellt ihr nicht irgendwie 30 Fragen, sondern vier. Vier ganz einfache Fragen. Oder Fragen Kontexte, könnte man sagen. Also erste Frage: Wo behandeln wir etwas als planbar, obwohl wir eigentlich lernen müssten? Das wäre so die erste Frage. Dann zweite Frage wäre, wo behandeln wir etwas als offen und agil, obwohl wir eigentlich Verbindlichkeit brauchen? Dritte Frage wäre dann, wo pflegen wir dieselbe Information mehrfach? Das ist natürlich eine unangenehme Frage, aber naja, braucht es schon auch so ein bisschen. Und dann gibt es noch die vierte Frage und da geht es eben einfach darum, welche Wahrheit gilt im Konflikt? Und das ist eine ganz wichtige Frage stellen. Also welche Wahrheit gilt dann, wenn wir uns nicht einig sind. Und übrigens bei Phoenix könnte die Wahrheit zum Beispiel so aussehen, dass das agile Board die operative Wahrheit für Teamarbeit und Sprintfortschritt zeigt. Und der Meilenstein-Plan ist eine verbindliche Managementsicht für externe Termine und Abhängigkeiten. Und PowerPoint zeigt nicht irgendwie zehn Aktivitätsfolien, sondern drei Entscheidungsfragen. Was ist entschieden, was ist gefährdet und welche Entscheidung muss der Lenkungskreis treffen? Und im Chat ist nur Kommunikation und nicht Governance. Das ist wichtig. Chat ist kein Entscheidungsspeicher. Das ist ein guter Ort, um Dinge schnell zu klären. Aber wenn dort Entscheidungen getroffen werden, die später niemand sauber wiederfindet, dann habt ihr kein modernes Arbeiten. Ja, dann ist es irgendwie Flurabstimmung oder sonst irgendwas. Und nach einem System Retro ist nicht alles einfach. Datenqualität ist immer noch schwierig, der Termin ist immer noch ambitioniert und das Projekt ist aber steuerbarer. Und das ist der entscheidende Punkt. Professionelles hybrides Projektmanagement nimmt die Spannung nicht weg. Es macht sie, wie das so schön heißt, führbar. Und das ist vielleicht der wichtigste Satz, der in dieser Folge sein könnte.

Hybridarchitektur-Check Und Montags-Move

SPEAKER_02 40:52

Hybrid ist nicht die Abwesenheit von Spannung. Hybrid ist die bewusste Gestaltung von Spannung. Und dafür braucht es halt irgendwie einen einfachen Check. Und da, wie gesagt, kann ich dir einen Hybridarchitektur-Check an die Hand geben. Das ist kein Methoden-Check. Denn die Frage ist halt nicht, habt ihr Scrum richtig gemacht oder ist euer Meilensteinplan gut oder das Tool sauber aufgesetzt? Die Frage ist, ist euer hybrides Projekt als Steuerungssystem gebaut? Und dafür schauen wir einfach auf vier ganz einfache Felder. Planen, Lernen, Entscheiden und Wahrheit. Und planen bedeutet einfach, also was ist wirklich planbar? Und was nicht. Also was hätten wir gern planbar? Das ist nicht die Frage. Sondern was ist wirklich planbar, weil es bekannt, stabil, wiederholbar und verbindlich ist. Und das ist aus der Perspektive Planbarkeit eine ganz entscheidende Frage stellen. Dann kommt Lernen. Und das ist eben die Perspektive, was ist wirklich unsicher. Und auch das ernst gemeint. Also nicht irgendwie, was wollen wir nicht planen, weil es unbequem ist und auch nicht, wo haben wir keine Lust, uns festzulegen, sondern was können wir am Anfang noch nicht seriös wissen. Das ist die alles entscheidende Frage. Und Hybrid braucht natürlich beides. Es braucht Planbarkeit und es braucht eben Lernen, Iteration, das kennst du. Und dann kommt eben Feld 3 sozusagen. Und das ist eben das Entscheidende. Das ist mehr oder weniger der Kern des Ganzen. Entscheidungen sind immer der Kern im Projekt. Wer darf im Konflikt was entscheiden? Nicht auf irgendwie einer schönen Rollenfolie und nicht irgendwie mit kick-off-freundlichem Nicken, sondern im Konflikt. Also wenn es darum geht, Zeit, Budget, Scope, Qualität und Nutzen irgendwie wieder auseinanderzufieseln, weil sie gerade miteinander kollidiert sind. Wer entscheidet dann? Das ist, und für alle anderen Fragen natürlich auch Termine, Ressourcen, Risiken, die ganzen Geschichten, die eben einfach auch entschieden werden müssen. Und dazu kommen wir dann zu Feld Nummer vier, und das ist die Wahrheit. Und da ist halt einfach die Frage, welches System gilt im Zweifel. Also das ist der Teil, den ganz, ganz viele halt einfach unterschätzen, weil da wird über Methoden geredet, über Rollen, über Springlänge und Tool-Auswahl. Was aber nicht geklärt ist, ist, wo ist die operative Wahrheit? Also wo liegt die Managementsicht und wie hängen Backlog und Meilenstein-Plan wirklich zusammen? Weil die müssen zusammenhängen, sonst funktioniert das Ganze nicht. Und da ist halt dann die Frage, welche Reports helfen bei Entscheidungen? Und Und welche Reports erzeugen nur Aufwand? Und vielleicht auch noch die Frage, was passiert, wenn zwei Systeme verschiedene Signale senden? Und übrigens, PowerPoint ist halt da nicht die Hilfe an der Stelle. PowerPoint ist nur. Ja, und was ist da wichtig? Oder das wäre jetzt im Prinzip schon der Montag-Move. Nimm dir halt einfach mal 60 Minuten, nicht allein, sondern mit den richtigen Personen aus deinem Team und schau dir das Ganze in 60 Minuten mal an. Sozusagen im Hybrid-Klartext-Meeting. Und wie der Ablauf genau sein könnte, das habe ich dir übrigens in den One-Pager gelegt. Also eine Stunde für dich optimal geplant. Und wenn ihr das dann durchgezogen habt, dann habt ihr plötzlich ganz viel Klarheit. Und lasst uns das doch einfach mal zusammenfassen. Hybrides Projektmanagement ist nicht falsch. Es ist auch nicht automatisch moderner. Es ist ein Ansatz, der so sehr gut funktionieren kann, wenn das Projekt tatsächlich unterschiedliche Logiken braucht. Planbare Teile brauchen Planung, unsichere Teile brauchen Lernen. Und das ist genau der Kern. Aber Hybrid kippt, wenn daraus ein Methodenbuffet wird. Ein bisschen Scrum, ein bisschen Gunt, ein bisschen PMO, ein bisschen Daddy. Wir bauen uns möglicherweise eine doppelte Bürokratie. Wir bauen uns eine doppelte Bürokratie, so muss es richtig. Und zwar nicht, weil Menschen dumm sind, sondern weil das System unklar ist. Das Team pflegt den Bord, die Projektleitung pflegt den Plan und so weiter. Alle arbeiten irgendwie und nicht unbedingt am selben Bild. Das macht alles keinen Sinn. Deshalb ist Hybridarchitektur ein ganz wichtiger Aspekt und der Hybridarchitektur-Check, den ich dir empfehlen möchte. Also plane, lernen, entscheiden und wahrheit die vier Felder bzw. die vier Chancen aus Methodenbreisteuerung zu machen, ist halt das Elementare. Und wenn du aus dieser Folge eine Sache mitnimmst, dann vielleicht diese. Hybrid ist kein Weg, unbequeme Entscheidungen zu vermeiden, sondern Hybrid ist ein Weg, sie früher sichtbar zu machen. Und

Kernbotschaft Und Abschlussfrage

SPEAKER_02 46:36

dann sind wir doch auch schon wieder bei meiner Endfrage an dich. In jeder Folge ist das ja so. Und zwar, welche Entscheidung versteckt ihr gerade hinter dem Wort Hybrid? Und übrigens, wenn dir diese Folge geholfen hat, dann abonniere doch gerne den Podcast und teil sie vielleicht mit jemandem, mit deinem Team, der gerade im Sprintboard, im Meilenstein-Plan und dem Lenkungskreis festhängt. Den Architekturcheck findest du wie immer verlinkt in den Shownotes. Und ja, dann sage ich einfach nur Danke, dass du heute wieder mit dabei warst. Und ich freue mich, wenn wir uns das nächste Mal hier wiedersehen bei Einfachprojekte. Und bis dahin wünsche ich dir 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.