Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 8 Episoden

Authentizität, Fehlertoleranz und Checklisten

Drei unterschätzte Erfolgsfaktoren im IT-Projektmanagement

10.06.2025 22 min

Zusammenfassung & Show Notes

In dieser Folge spricht Andreas Weller mit dem erfahrenen IT-Projektmanager Andreas Wünsch über zentrale Prinzipien erfolgreicher Projektarbeit – mit einem Fokus auf Authentizität, Fehlertoleranz und Checklisten. Andreas Wünsch gibt praxisnahe Einblicke aus über 25 Jahren Projekterfahrung in internationalen IT-Umfeldern und erläutert, wie einfache Maßnahmen große Wirkung entfalten können.

Kernthemen:

Warum es essenziell ist, im Projektalltag authentisch zu bleiben
Wie man durch konsequente Fehlerkommunikation Vertrauen schafft
Wie Checklisten selbst erfahrene Experten vor Ausfällen bewahren
Warum Prozesse oft an internen Silos scheitern – und wie man das durch aktives Nachfragen verhindern kann
Weshalb es Mut braucht, sich gegen die Meinung des Kunden zu stellen – und wie daraus langfristige Wertschätzung entstehen kann

📢 Episode: Authentizität, Fehlertoleranz & Checklisten – Drei unterschätzte Erfolgsfaktoren im IT-Projektmanagement

🎙 Gast: Andreas Wünsch - Senior IT-Projektmanager & Troubleshooter
🎙 Gastgeber: Andreas Weller - Managing Director der Sidekick Network GmbH

🎯 Thema: Warum echte Kommunikation, pragmatische Tools und Klartext mehr bewirken als jede Methodendiskussion.

🔍 In dieser Episode erfährst du:

✅ Wie Authentizität hilft, Stress in Projekten besser zu bewältigen
✅ Warum gerade Routiniers von Checklisten profitieren
✅ Was eine gute Fehlerkultur mit Vertrauen zu tun hat
✅ Warum du Prozesse wirklich bis zum Ende denken musst – und wer das tun sollte

📌 Highlights:

[00:00] – Begrüßung & Vorstellung Andreas Wünsch
[03:03] – Wie Checklisten Nachtschichten retten können
[06:27] – Warum die Experten öfter Fehler machen als die Neuen
[07:17] – Prozessdenken mit Beispielen aus Möbel- & Autoindustrie
[10:04] – Serverbereitstellung in Rekordzeit – durch klares Prozessverständnis
[13:26] – Process Owner: Titel oder echte Verantwortung?
[15:22] – Fehler zugeben statt vertuschen – so entsteht Vertrauen
[18:47] – Warum Klartext manchmal erst später geschätzt wird
[20:28] – Fazit & Learnings für deinen Projektalltag

🎧 Jetzt anhören & echte Projekterfahrung mitnehmen!
👉 LINK

🔔 Abonniere den Podcast, um keine Folge zu verpassen! 🚀

📎 Mehr Infos zu Andreas Wünsch:
👉 https://www.linkedin.com/in/andreas-wuensch-itconsulting/

📎 Mehr über Sidekick Network:
👉 https://www.linkedin.com/company/sidekick-network/

Transkript

One, two, three, four. Hallo und herzlich willkommen bei Smart Hacks für IT Projektmanager, präsentiert von Sidekick Network basiert unser Podcast auf der Erfahrung von über 20.000 IT Projekten. Bist du bereit? Direkt zum Punkt zu kommen? Dann lass uns starten. Herzlich willkommen zur heutigen Folge mit unserem Gastexperten Andreas Wünsch. Andreas ist ein sehr erfahrener IT Projektmanager, der seit über 25 Jahren komplexe IT Projekte auf internationaler Ebene begleitet und erfolgreich umsetzt. Er hat zahlreiche Projekte davon geleitet, in denen es entscheidend war, klare Strukturen und Prozesse einzuführen, um sowohl technische als auch organisatorische Herausforderungen zu meistern. Dabei hat er viel Erfahrung in den Themen Authentizität, Fehlertoleranz und pragmatische Vorgehensweisen sammeln können, die er heute mit uns teilt. Ich freue mich auf das Gespräch. Hallo, Andreas. Hi. Hallo Andreas. Heute sprechen wir über Themen, die sonst nicht so zur Sprache kommen. Oder manchmal auch einfach vorausgesetzt werden. Heute geht es nämlich um Authentizität. Das Wort habe ich dreimal geübt, damit es passt. Wir sprechen über Fehlertoleranz und wir sprechen über Checklisten. Warum hast du heute genau diese drei Aspekte für uns mitgebracht? Ja, Projektarbeit an sich ist ja schon eine sehr große Herausforderung. Und wenn ich mir die Ausschreibung anschaue, da werden dann Superhelden gesucht. Es fehlt noch, dass man fliegen können muss. Aber so jemand gibt es ja in der Realität nicht. Und ich bin auch nicht so gestrickt. Also sage ich mir Das Einfachste ist, so zu sein, wie man ist, wie man sich wohlfühlt. Das hat auch mit dem Energiehaushalt zu tun. Das heißt, wenn ich mich die ganze Zeit verstelle und irgendjemand versucht zu sein, der ich gar nicht bin. Das wird nur eine gewisse Zeit lang gut gehen und es funktioniert vor allem dann unter Stress nicht Und Stress. Das kennen wir, das gibt es ja ohne Ende. Und was führt zu Stress? Fehler meistens. Ich rede da nicht von den Kleinen, die jeden Tag vorkommen, sondern von wirklich schwerwiegenden. Und da ist meine Haltung. Sobald du erkennst, es ist was wirklich schief gelaufen, Dazu stehen, offen legen, gar nicht lange drumherum reden. Da ist natürlich das Bestreben, die Anzahl der schweren Fehler möglichst gering zu halten. Und da hilft mir immer wieder Kleinigkeiten wie wie, wie Checklisten, Runbooks, Rezepte, wie immer man das nennt, bei den einzelnen Kunden auch nennen möchte, weil das gibt Sicherheit. Ja, dann lass uns doch mal mit den Checklisten anfangen. Du hast da ein konkretes Beispiel aus der Praxis mitgebracht, bei dem Checklisten entscheidend waren. Was war die Herausforderung bei dem Projekt im Speziellen? In dem Fall war ich Service Delivery Manager bei einem globalen Kunden im sieben mal 24 Stunden Betrieb. Wir hatten die Aufgabe, die die Applikation zu betreiben, die der Kunde weltweit genutzt hat. Der Betrieb der Serverwartungen Patches Maintenance lag in einer anderen Gruppe. Und jetzt kam es immer wieder vor. Natürlich wurden dann ChangeWindows definiert. Das hat alles funktioniert. Und dann haben die Kollegen, die für die Serverwartung zuständig waren, die die Dienste runtergefahren, Datenbanken gestoppt, Server runtergefahren, gepatcht, alles gemacht, bis auf den letzten Schritt, die Datenbanken wieder zu starten. Das heißt die Applikation lief nicht. Das heißt, meine Kollegen, die im 724 Stunden Dienst standen, wurden morgens um drei durch die Australier geweckt, die gemerkt haben, sie kommen nicht auf die. Auf die Maschine drauf. War aber nicht die Maschine. Die Datenbank war einfach nicht da. Und das ist eine einfache Sache, die man schnell in den Griff kriegen kann, indem du dir die Schritte aufschreibst. Was muss ich tun, wenn ich die Server stoppe? Und was muss ich tun, wenn ich sie starte? Klingt eigentlich banal, aber du hattest ja auch schon erzählt in mehreren Gesprächen vorher, dass meist diese Fehler gar nicht den Rookies passieren, sondern denen, die denken, dass sie das eigentlich schon alles draufhaben. Ja, das war genau der Punkt. In unserer kleinen Gruppe waren wir sechs Personen, die diesen diesen 724 Service bereitstellen mussten. Und wir hatten aber nur drei echte Spezialisten und drei neue Kollegen. Und was haben wir da gemacht in Onenote? Einfach eine Checkliste gemacht. Also es ging meistens darum, Objekte zu verteilen innerhalb verschiedene Umgebungen, von der Test in die IT, in die Produktion. Und das ist alles eigentlich keine Hexenwissenschaft. Aber wenn du morgens um drei geweckt wirst, bist du nachts auch noch schlaftrunken, stehst auf, setzt sich an den Rechner, liest. Was ist eigentlich los? Musste ich erst wieder denken. Und dann machst du das, was du tun musst. Dann ist ruckzuck einer von zehn Schritten vergessen. Das ist das passiert. Und deswegen haben wir da wirklich Schritt für Schritt für. Ganz einfach. Du musst natürlich wissen, was du tun musst. Aber wenn du die Punkte wieder siehst, dann ist dir ganz klar Ah ja, das, dass das eigentlich total simpel, total simpel. Dann haben wir die Leute dazu gezwungen. Ihr müsst auch abhaken. Also da war so eine kleine Checkliste, Klick, klick, klick, klick und wenn irgendwas schief ging, dann konnte man nachgucken Hast du die Checkliste ausgefüllt und wo sind die Haken? Und wehe, da war ein Haken. Aber der Schritt wurde nicht gemacht. Das ist ja auch nicht der Sinn der Sache. Einfach die Checkliste abhaken, aber den Job nicht erledigen. Und interessanterweise war es tatsächlich so die Cracks, die das schon Jahre gemacht haben, die dachten auch so eine Checkliste brauche ich nicht. Und da sind dann echt Fehler passiert. Und die jungen Wilden? Die haben sich an die Checkliste gehalten. Da ist so gut wie nie etwas vorgekommen. Und das war für mich einfach interessant zu sehen, so in real life. Was man machen kann, ohne große Technologie und Zauberei. Ja, ja, okay. Und du bist ja bei vielen Themen, also das war vielleicht jetzt schon der erste Hack, den man vielleicht mitgeben kann, auch wenn das für manche zu banal klingt. Aber erstmal machen. Ja, ja, erst mal den Mut haben, sowas auch einzuführen und zu sagen Ey, ihr macht jetzt die verdammte Liste. Ja, genau. Aber du hast ja aus eigener Erfahrung schmerzliche Erfahrung, was das bedeuten kann, wenn sowas nicht läuft. Ja, ja, du hast ja meistens Projekte, die sich von oder mit End to End Prozessen beschäftigen. Ja, da helfen natürlich diese Checklisten in den einzelnen Teilbereichen. Aber wie kann man denn sicherstellen, dass dann auch die Gesamtprozesse am Ende funktionieren und dann ein Rad ins andere greift. Vielleicht auch schon die Überleitung zu deinem zweiten Hack, den du heute mitgebracht hast. Tja, das ist natürlich, sagen wir mal an einem Beispiel. Kann ich das vielleicht mal erläutern? So diese übergreifenden Prozesse aus dem Bereich Möbelindustrie oder Möbelhandel. Da war es so, die die Zielvorgabe für den Einkauf war Kosten drücken. Also praktisch beim Einkauf sparen und möglichst wenig bezahlen für die Produkte. Das haben sie dann auch gemacht. Das hat natürlich Reaktionen auf Seiten der Lieferanten nach sich gezogen. Sie haben praktisch die Möbel nicht mehr teil aufgebaut, sondern wirklich komplett zerlegt geliefert. Also wenn man in den letzten Jahren mal ein Ikea Regal gekauft hat mit Schubladen, dann weiß man, was das heißt. Und das bedeutet im Endeffekt auf der Auslieferungsseite die Möbel müssen ja auch montiert werden und nicht jeder baut selbst auf. Das heißt, dann haben die, die, die die Kunden sich die Möbel liefern lassen Und dann mussten die Möbel Monteure, wo sie vorher 15 Minuten gebraucht haben, haben zwei Mann da eine Dreiviertelstunde gestanden und geschraubt. Der Witz war Der Verkaufspreis des Artikels ist gleich geblieben. Das heißt, für die Monteure, die nach Umsatz sozusagen auch teilweise bezahlt wurden, hat sich der Wert, den sie bekommen haben, dafür nicht geändert. Aber sie hatten die doppelte bis dreifache Zeit. Und das war so ein ganz typisches Beispiel für. Am Anfang war es gespart, am Ende aber Geld draufgelegt. Anderes Beispiel auch Automobilindustrie. Wir hatten einen Kunden, der hat in der Ukraine produziert. Ist schon Jahre her, nicht in der aktuellen Situation und hat dann ein zentrales Lager in Belgien beschickt. Und von dort aus haben wir dann Teile nach Polen zurückgeschickt. Da habe ich dann dem Automobilkunden gesagt, ich sehe hier in sechs Prozent der Teile die Liefer, die von der Ukraine durch halb Europa nach Belgien und dann wieder zurück nach Polen. Wäre es nicht besser, wenn ihr die Teile, die ihr in Polen braucht, direkt aus der Ukraine liefern lasst? Und das sagte der vom Einkauf? Ja, das wäre eine gute Idee, aber ist ein anderer Bereich. Hat mit mir nichts zu tun. Das bedeutet auch wieder innerhalb des Konzerns des Automobilherstellers keine keine klare Zusammenarbeit in Richtung auf Optimierung und. Kosteneinsparungen, sondern jeder sieht nur sein Sein, Sein, seinen Teilbereich. Also das Thema sozusagen ein Prozesseigner Process Owner definierender von Anfang bis Ende zu Ende denkt auch das Thema. Ich glaube, du hast da auch noch mit Servern an vier verschiedenen Standorten in vier verschiedenen Abteilungen, wo dann einfach nicht alles von Anfang bis Ende beachtet wurde. Ja, das ist. Das ist genau das Nächste. Bei einem Kunden war ich eingekauft, um die Lieferzeit der Server, die er bestellt hat, zu minimieren. Das hat so 6 bis 8 Wochen gedauert, wenn ein Server bestellt hat. Linux Server mit bestimmten Datenbanken, bestimmte Konfiguration 6 bis 8 Wochen und das dauert so lange. Das kann nicht sein. Wir haben so viel Druck, das muss schneller gehen. Und da habe ich gesagt, hat er mich eingekauft und ich hatte keine Ahnung von Server aufbauen. Und ich habe mich dann gefragt Wer ist überhaupt beteiligt bei dem Aufbau eines Servers und wer muss etwas tun in der Konfiguration, im Setup, in den Einrichtungen der verschiedenen Bereiche? Und das waren so 4 bis 5 Abteilungen innerhalb der Firma, für die ich gearbeitet habe. Die kannten sich aber nicht, die hatten auch nichts mit mir zu tun. Es gab keine Übergabeschnittstellen, es gab nur für den Anfang eine mehr oder weniger krude Anforderungen. Ich brauche einen Server, Das ist jetzt ein bisschen grob, aber sehr viel mehr war nicht drin. Das heißt, an der ersten Stelle hat es schon gestockt, weil sich keiner drum gekümmert hat, dass die Abteilung, die liefern musste, die relevanten Informationen hatte. Und als die dann die Informationen hatte, habe ich ihnen dann besorgt. Dann ging es an die nächste Stelle weiter. Und die war genauso. Die wusste gar nicht, wann die erste Stelle fertig ist, um dann weiter zu machen. Und ich habe dann Moderator gespielt, sozusagen über die gesamte Kette. Und zum Schluss hatten wir, glaube ich, Lieferzeiten von etwa zwei Wochen. Ich habe es dann noch optimiert. Sozusagen das Thema an dich gerissen. Ich habe das so gemacht, ich habe das gemacht. Finde ich ja auch klasse. Ich meine, du bist ja jetzt kein Junior mehr, oder? Ohne dir zu nahe zu treten, aber nein, du bist sozusagen, kommst in Projekte rein und egal wie Senior du bist, du greifst zum Telefon und versuchst das Thema von vorn bis hinten zu verstehen. Und die Beteiligten? Ja. Das ist genau der Punkt. Weil man kann sich jetzt natürlich in Nebensätzen und sagen Ach, das schadet, das funktioniert alles nicht, aber das bringt einen ja nicht weiter. Und egal was ich mache, in den in den Projekten auf Arbeitslevel muss ich verstehen, was passiert. Und da bin ich eigentlich recht gut, weil ich in den technischen Bereichen nicht immer das Detailwissen habe. Das heißt, ich muss sehr viel fragen und wenn ich mich rumfrage, dann kommst du auf überraschende Erkenntnisse und Ergebnisse. Und die sammele ich dann bereitet die mir auf oder für das Team auf und dann können wir daran weiterarbeiten. Das ist manchmal ganz, ganz basic. Also das ist. Total. Ja, genau. Wir haben das mal bei einem Messeanbieter gemacht, haben da Prozessworkshops gemacht und dann alle Beteiligten zusammen. Und da kam raus, wie Prozesse bei denen ablaufen. Und selbst die eigenen Mitarbeiter wussten das teilweise gar nicht oder waren total überrascht, dass sie einen Punkt haben. Ja. Ja, ja, ja, ja, das sehe ich eigentlich auch immer wieder, gerade bei größeren Firmen, so Onboarding von von, von neuen Mitarbeitern. Gerade Externe, also große Firmen haben ja sehr viele externe. Da sollte das eigentlich gehen wie das Brezelbacken. Das ist manchmal wirklich brutal, wie viel Schritte das sind, wo es hängen kann und wie man erkennt, wo es hängt. Da brauchst du aber wirklich Nerven wie Drahtseile und viel Liebe zum Detail, weil du musst dich einfach durchfragen. Das ist und das ist glaube ich, das, was dann viele abschreckt, weil sie wissen nicht, wo sie hingehen sollen, wen sie fragen sollen und. Wem sie vielleicht auf den Fuß treten. Vielleicht ist ja irgendwo ein Process Owner definiert, aber das haben wir ja auch schon gelernt. Ist eigentlich nicht immer wichtig, dass in einer bestimmten Abteilung der Process Owner hängt, weil es organisatorisch irgendwo aufgehangen ist, sondern mehr nach der Sinnhaftigkeit. Bzw. Welche Person ist das? Kümmert die sich wirklich. Und und die Frage, das habe ich auch schon gesehen, gerade bei Application Owner. Bei meinem letzten Kunden, bei dem ich war, da gab es die Rolle des Application Owner ist jetzt gerade Upgrade Windows zehn elf, da müssen verschiedene Applikationen getestet werden. Gerade wenn man jetzt sagen wir mal, in die Cloud geht, da läuft das alles ein bisschen anders als On Prem. Was ist das Verständnis des Application Owners von seiner Aufgabe? Hat er das gleiche Verständnis von dem, was ich jetzt denke, Dass der alles testet im Detail, dass er das übergibt, das heißt dokumentiert oder hat er ein ganz anderes Verständnis? Also auch das Thema Process Owner wird ja das habe ich auch gesehen, von vielen Leuten unterschiedlich gelebt, je nachdem, ob sie das, ob sie es gerne machen oder jetzt kommt's. Ist der Prozess auch eine freiwillige? Oder wurde er dazu überredet? Ja, überredet. Und so wird das dann auch oft gelebt. Ja, ja, jetzt haben wir natürlich einen großen Schwung gemacht. Wir sind von Checklisten gekommen und sind jetzt schon beim Thema Process Owner, was wir gar nicht angeteasert haben. Aber ich fand es ganz interessant. Ja, ein Thema sollten wir, denke ich, unbedingt beleuchten. Und das ist das Thema Fehlerkultur und damit verbunden auch das Thema. Ich versuche es noch mal ohne Pickup. Authentizität? Ja, zehnmal schnell sagen. Mal sehen, ob man es schafft. Ja. Das heißt, wir haben über das jetzt gesprochen, über die Checkliste und die die Notwendigkeit von Prozessordnungen. Das schützt ja aber trotzdem nicht, dass auch mal ein Fehler gemacht wird. Und aus deiner Erfahrung, Wie geht man da am besten damit um? Weil früher oder später passiert ja passiert auch mal was? Ja, ja, natürlich. Also ich sage, was aus meiner Sicht für den Kunden am wichtigsten ist, ist Berechenbarkeit und Zuverlässigkeit. Weil der kennt einen ja auch nicht als Externen. Ja, das bedeutet, wenn etwas passiert und ich gehe proaktiv auf meinen internen Sponsor, Projektleiter oder wie immer man das nennen will zu und sage hier pass mal auf, das und das ist vorgefallen, dann schütze ich ihn ja dadurch, weil ich kann natürlich hoffen, es fällt nicht auf. So Duck and cover ja, aber das passiert in der Regel nicht. Also wenn. Wenn. Und wenn. Wenn es auffällt, wenn es auffällt, dann ist wirklich. Dann ist es vielleicht schon zu spät. Wenn es früh genug auffällt, dann kann man ja oft noch was machen, dann kann man das noch verkaufen. Als Ja, hier ist es aufgefallen und wir haben es jetzt gemerkt und wir können es optimieren, Wir können es verbessern, was auch immer. Aber wenn ich das nicht mache und einfach so en passant passieren lasse. Früher oder später kommt es auf und dann denkt er sich Ich bin unfähig und erkenne nicht mal, dass was falsch gelaufen ist. Also dieses Thema Fehler totschweigen halte ich für sehr, sehr, sehr riskant. Natürlich, das tut weh, wenn man Fehler gemacht hat. Aber ich hatte auch schon große Lacher. Ich habe mal an Mails geschrieben zum Thema hier Leute, ihr müsst das und das und das machen und habe aus der Excel Liste die falsche Spalte genommen. Ich habe nicht die User, ich hatte deren Vorgesetzte und das waren bisweilen relativ High Level Leute, die haben die Mail bekommen, wussten gar nicht, was was los ist. Die haben dann ihrerseits wieder sauber gemacht. Das kam dann zu mir rum, bis dann mein Sponsor kam Sag mal, was passiert, Was ist da los? Sag ich. Oh ja, äh, habe ich die falsche Excel Spalte kopiert? Tut mir leid. Und da sagten die Na ja, ist ja nicht schlimm, dann wissen die jetzt jedenfalls, dass was passiert. Ja, sage ich ja auch. Gut, auch eine Art von Kommunikation. Also es ist nicht mal immer so dramatisch. Natürlich. Die Leute haben gesagt, Was ist denn los? Wieso? Wieso schreibst du die an? Das kann doch nicht sein. Ja, aber das passiert halt. Und dann hätte ich auch sagen können. Oh ja. Weiß ich nicht. Mein Kollege und so. Nö, das habe ich falsch gemacht. Punkt. Und wie gesagt, das ist wichtig. Ich will ja nachts ruhig schlafen können. Also, wenn ich weiß, dass irgendwas Gravierendes passiert ist und ich hoffe, das geht irgendwie an mir vorüber, dass, äh. Die Zeiten sind vorbei. Die Nerven habe ich nicht. Der Kunde weiß, der Kunde weiß ja im Endeffekt auch, dass du ihm nichts verschweigen wirst, dass du genau das offensiv kommunizierst. Weil oftmals passieren ja Dinge und dann wird erst mal gesucht. Wo ist der Fehler? Und dann vergeht wichtige, kostbare Zeit. Genau. Und hätte man es eher angesprochen, wäre es vielleicht gar nicht so schlimm geworden. Das ist. Das ist genau das Thema, was ich meine mit Berechenbarkeit und Zuverlässigkeit. Du musst berechenbar sein. Also wenn die wissen, es passiert was und ich melde das, dann ist das was ganz anderes, als wenn sie sagen Oh, der hat schon dreimal Mist gebaut. Und bis wir es rausbekommen haben. Das hat auch wieder ewig gedauert und das zermürbt einfach und das ist mir meine Nerven zu schade. Ja, das ist so! Dann lieber einmal, dann lieber einmal kurz und knackig durch und dann ist es halt so! Ja. Da hast du nicht auch mal so ein Thema, wo du gesagt hast, du denkst, dass das nicht funktionieren wird und du bist einfach bei der Meinung geblieben und dann hast du den Kunden erstmal verprellt. Ist das der Falsche? Nein. Im ersten Moment. Das ist genau so! Er hatte eine andere Auffassung, wie man den Upgrade von seiner Software durchführen sollte. Er wollte, um es kurz zu sagen, er wollte alle Modifikationen, die sie gemacht haben, 2000 irgendwas im alten System auf das neue System rüberbringen und dann im neuen System sehen, was man abschalten kann. Ich habe gesagt Nee, nee, nee, nee, das machen wir anders. Wir fangen mit null Modifikationen an, sehen, was das neue System kann und modifizieren dann, wenn es nötig ist nach weil ansonsten zahlt ihr ja zweimal zahlt das die Modification reinkommt erstmal um dann vielleicht später zu sagen Oh jetzt kann ich sie rausnehmen, hab ich gesagt, mach ich nicht. Und er war strikt und stur dagegen hab ich gesagt Nee, dann ja. Der Effekt war, man hat sich dann bei der nächsten Möglichkeit für einen anderen Projektleiter entschieden. Ich war dann raus und so sechs Wochen später ruft mein Chef an und sagt Oh, der Kunde hat wieder angerufen. Ein bisschen peinlich. Er möchte, dass du in dem Projekt mitarbeitet. Sage ich Ja, wo ist das Problem? Sagt er Na ja, du warst ja da Projektleiter, aber jetzt wärst du dann nur Projektmitarbeiter Und solltest dann halt mitarbeiten. Sage ich Ja, Wo ist das Problem? Ich sagte ja, es wäre ihm so peinlich, aber er schätzt meine Art, weil ich dafür stehe, was ich sage, auch wenn es nicht das ist, was er hören wollte. Aber im Endeffekt. Er weiß, woran er dran ist. Er weiß, woran er dran ist. Ganz genau. Und dann habe ich da mitgearbeitet und alles war gut. Ja. Ja, ja. Gut. Dann haben wir heute einige Themen besprochen. Einerseits das Thema Checklisten, Erster sozusagen. Das ist ja auch ein Zwingen der Mitarbeiter zum Beschäftigen mit dem Prozess. Ganz genau. Schafft ja auch Verständnis. Das ist der nächste Punkt. Du weißt, was gemacht wird. Und das merkst du gerade, wenn du. Wenn du zum Thema Installation von Infrastruktur, Server oder sowas dann hat. Dann haben die Techniker immer eine super gute, haben gute Ideen, haben einen tollen Überblick. Aber das letzte Detail, was gemacht werden muss, das fehlt dann manchmal. Oder der eine hat es, der andere macht es, der nächste macht es wieder nicht, weil er es nicht genau weiß. Also das ist riskant. Je mehr Schritte das sind, umso riskanter wird das. Schafft ja auch Sicherheit. Das wird reproduzierbar. Und ja, es hilft ja auch, sage ich mal, wenn du eine hohe Fluktuation im Team hast, dann neue Kollegen schnell reinzuholen. Das ist genau der Punkt. Das ist genau der Punkt. Aber ja. Dann haben wir das Thema Process Owner also wirklich von Anfang bis Ende durchzuziehen und eher darauf zu achten, dass man engagierten Mitarbeiter oder Mitarbeiterinnen hat, die das auch wirklich machen wollen und sich da reinhängen. Und das letzte Thema Mut zur Authentizität. Fehler melden, Wirklich auch mal die Hand heben und sagen Hey, da ist was passiert. Und den Mut haben, das dann auch durchzuziehen. Ja, ja, ja. Dann vielen Dank, Andreas, dass du diese Themen heute mit uns geteilt hast. Wer noch mehr zu Andreas erfahren möchte. Also ich kann es nur ans Herz legen, der kann in den Shownotes noch die Kontaktdaten von Andreas sehen. Ansonsten vielen Dank, dass du da warst und ich freue mich, dass wir uns vielleicht auch noch mal auf eine weitere Podcast zusammenschalten. Ja, sehr schön. Vielen Dank, dass ich hier sein konnte. Danke schön. Danke dir. Mach's gut. Tschüss. Tschüss. Tschüss. Ist ja gut.