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.
Heute begrüße ich Oliver Ink, einen erfahrenen PMO Experten und
Projektmanager, der weiß, was es braucht, um große IT Workloads
erfolgreich zu begleiten.
Wir besprechen, warum ein starkes PMO der Schlüssel zu einem effektiven
Projektmanagement ist und wie er als Projektleiter dabei unterstützt, selbst
die größten Herausforderungen zu meistern.
Oliver hat drei Hacks mitgebracht, die wir heute miteinander besprechen.
Hallo Oliver. Hallo Andreas.
Du hast ja schon viele PMOs für komplexe Projekte aufgesetzt und durchgeführt.
Was sind denn aus deiner Sicht die Voraussetzungen, um erst mal so ein IT
Projektleiter und Projektleiterin des PMO effektiv zu unterstützen.
Da würde ich jetzt am Anfang direkt mal zwischen zwei Use Cases unterscheiden.
Zum einen dazwischen ein komplett neues Projekt aufzusetzen oder aber, wenn man
in ein bereits bestehendes Projekt kommt.
Da muss man eben die gewachsene Landschaft mit berücksichtigen, verstehen
und gegebenenfalls anpassen.
In beiden Fällen sind allerdings die Aktivitäten als PMO erst einmal dieselben.
Was man allerdings sagen kann, ist, dass die
Aktivitäten für ein neues Projekt natürlich schneller umzusetzen sind und in
ein bestehendes Projekt zu kommen meist mehr Zeit verlangt.
Die Voraussetzung ist, dass man den Projekt scope versteht.
Ich als PMO gleichzeitig Challenge Ich.
Gibt es eine Art ProjektCharter für das gesamte Team?
Weil nicht nur ich muss das den Projekt scope oder das Projekt verstehen.
Das muss das Team, das müssen die Stakeholder.
Richtig.
Und das ist tatsächlich das Erste, was ich mache.
Sicherstellen.
Haben wir eine Art ProjektCharter in irgendeiner Weise als Deliverable,
als Dokument, als Lightdeck?
Und wenn wir das nicht haben, dann müssen wir da die groben Rahmenbedingungen
einmal skizzieren.
Und das challenge ich und dann wird es aufgesetzt.
In den meisten wird es aufgesetzt.
Auf jeden Fall, also in den meisten Projekten ist es ja auch so Was, was, wenn
es nicht da ist, immer ein großer Schmerz ist, sich dazu noch mal
zu bewegen, das zu tun.
Der Schmerz ist da richtig, aber mit der richtigen Argumentation
kriegt man die Leute auch dazu, sich dafür nochmal die Zeit zu nehmen.
Die ist meistens nicht da, Aber oft ist das einer der Grund der Gründe dafür,
warum es manchmal zu Stillstand im Projekt oder zu Scope Creep kommt.
Das einfach nicht kein gemein, kein gemeinsames Verständnis davon
besteht, was es unser Scope.
Ja, das Thema Scope Creep haben wir auch schon mal immer besprochen
im Detail mit Frank.
Vielleicht erinnern sich einige Hörer daran.
Ansonsten, wenn sie jetzt mal auf die Hacks zu kommen.
Es gibt ja da draußen ganz viel Literatur zum Projektmanagement, auch zu Programm
Offices und oftmals wird uns dann entgegengeworfen.
Naja, steht doch alles in den Büchern.
Deswegen reden wir heute nicht über Bücher.
Wir können jetzt nicht ganz vorab sehen, ob es vielleicht irgendwo steht, aber was
sind jetzt so die Sachen, die in der Praxis wirklich helfen aus deiner Sicht?
Du hast uns ja drei mitgebracht, die du auch immer wieder benutzt, die du
jetzt nicht unbedingt in der Schulung mitbekommen hast, aber die im täglichen,
in der täglichen Arbeit wirklich helfen.
Was sich bewährt hat, ist als dein erster Hack so ein One Page Dashboard.
Das heißt, dass man da eine standardisierte
Vorlage oder ein Dashboard benutzt, was Transparenz schafft und Übersichtlichkeit
für alle im Team, für alle Stakeholder mit klaren, immer gleichen Kriterien,
sodass auch für jeden jederzeit möglich ist, den Status einzusehen.
Ja, und das zweite geht dann eher so, das haben wir im Vorgespräch besprochen, das
ist sowas, was, was ich selbst ja noch nie wirklich umgesetzt habe.
Aber was ich echt cool finde.
Ja, spannend. Andreas, dann kannst du ja was lernen.
Nein, Also was sich total bewährt hat, ist Synergien zu nutzen.
Gerade im bestehenden Projekt reinzukommen und sofort erstmal
die die Hände, die Fühler auszustrecken nach den anderen PMOs, nach anderen Teams.
Was wird benutzt, Was können wir wiederverwenden?
Welche Templates, um einfach hier das Rad nicht neu zu
erfinden, sich Zeit zu sparen, effizient zu sein, gleichzeitig eben Strukturen zu
nutzen, die im Projekt schon bekannt sind, die in vielen Fällen auch Vorgaben sind,
von der Governance her, vom Programm.
Und das hilft einfach auf so vielen Ebenen.
Man connected mit anderen PMOs, man erweitert sein Netzwerk und hat einfach
direkt am Anfang schon den Austausch.
Gleichzeitig hilft man dem Team.
Gegebenenfalls gibt es ja auch mal einen Switch innerhalb des Projekts.
Alle kennen schon die Struktur, das Layout und das Wording und kann einfach
hier ganz, ganz viel nutzen.
Was schon wo Arbeit reingeflossen ist und was schon besteht.
Und man kann auch so einen kurzen Draht aufbauen zu den anderen PMOs.
Ja, diesen. Hotwire.
Genau das.
Wenn an einer Stelle des Projektes mal was passiert.
Wir reden ja über große IT Warlords mit mehr als 200 Mitarbeitern da in so einem
Team, dass man auch auf kurzem Wege gleich erfährt okay, da ist was
und Vertrauensbasis da ist.
Oftmals findet man ja das eher so vor, dass die PMOs jetzt nicht gegeneinander
arbeiten, aber dass jeder schon so ein bisschen abgeschottet sein Ding macht.
Brauche ich jetzt niemanden irgendwo die der Zacken aus der Krone fallen,
mal jemanden anderen anzusprechen.
Das ist ja eigentlich nur von Vorteil. Auf jeden Fall.
Das kann ich nur so teilen.
Es hilft da schon am Anfang.
Wie gesagt, wenn man reinkommt, mit den Leuten zu sprechen, regelmäßig im
Austausch zu bleiben und wenn es nur alle paar Wochen, Monate mal im
Chat ist, sich zu updaten.
Gibt es da was Neues oder hier?
Ich teile auch mal proaktiv ein Template, wenn ich das, wenn ich sage, das
könnte für euch relevant sein.
Und so bleibt man im Austausch, erfährt viel.
Und wie gesagt, man spart sich einfach enorm viel Arbeit, weil man
sie nicht doppelt macht.
Es müssen ja nicht zwei Silos parallel das gleiche aufbauen.
Wenn es das schon gibt.
Und es ist ja auch, sage ich mal, für das Projekt an sich selber schon mal sehr gut,
dass es dann nicht unterschiedliche Templates genutzt werden.
Jeder nutzt ein anderes Risikomanagementtemplate, was auch immer.
Das macht es ja viel einfacher, auch für jemanden, der da drauf schaut.
Richtig.
Und wenn man da nicht miteinander spricht, wo soll das Wissen herkommen?
Ja, ja, das finde ich.
Man könnte meinen, ein einfacher Hack, aber letzten Endes heißt das ja auch,
ich muss das Telefon in die Hand nehmen.
Oder ich muss die Kollegen wirklich aktiv ansprechen, mich vorstellen.
Und das auch, wenn man immer sagt, man ist ein sehr guter Kommunikator im
Projekt, da entscheidet es sich, ob man das wirklich ist.
Ja, das ist eben diese ganz, ich würde sagen fast entscheidende Phase,
am Anfang eines Projekts reinzugehen, proaktiv zu sein.
Das verliert nicht an Relevanz im weiteren Laufe des Projekts, weil die
Anforderungen ändern sich.
Die stakeholder ändern sich aber trotzdem immer wieder aktiv auf die Leute
zuzugehen, mit den Leuten zu sprechen, bleibt hier essenziell.
Ja, dann hast du noch einen dritten Hack für uns mitgebracht.
Ich würde den schon mal nennen und du kannst dann noch mal drauf
eingehen, was damit gemeint ist.
Don't hesitate to escalade.
Ja, das ist so ein Catchphrase.
Der hat ja, ich würde sagen, er ist auch verbunden zu dem Thema, was wir
eben genannt haben, kommunizieren.
Also dass das Vertrauen bei Stakeholdern wird dadurch erhöht.
Es wird Transparenz wieder geschaffen und es werden Missverständnisse verhindert.
Ein Teil des PMO ist natürlich, ein strukturiertes Risk
Management aufzusetzen.
Aber das funktioniert natürlich am Ende nur, wenn der Projektleiter auch eskaliert
und oder ein risk raised und nicht erst wartet, bis ein Issue ist,
sondern im frühen Stadium Dinge anspricht.
Das ist nicht nur auf Risiken im Projekt Projektbezogen.
Das ist eben, auch wenn wir jetzt noch mal den Bogen zurück zum Scope schlagen, wenn
da Unklarheiten sind, wenn da Fragen sind, eskalieren.
Wenn man es eskaliert, merkt man zum Beispiel auch vielleicht im nächsten
Schritt Oh, ich weiß gar nicht, an wen ich eskalieren muss.
Oh, die Rules of Responsibility sind nicht klar.
Und dann ist das ein Rattenschwanz.
Den Eskalation muss ja nicht was negatives sein.
Eskalation kann ja einfach nur sein.
Ich habe hier eine Frage.
Ja, Können wir das klären?
Das heißt ja am Ende nichts anderes, als einfach auf die nächste Ebene zu heben,
weil man sagt, ich komme jetzt hier nicht weiter mit meiner, mit meinem
Ansprechpartner im Projekt oder mit dem Third Party Vendor.
Ich gebe es auf die nächste Stufe, um dafür sicherzustellen, dass unser
Problem oder das, was wir gerade besprechen wollen, gelöst wird.
Aber wenn man das hinauszögert und den Punkt verpasst, dann fragt
natürlich jemand warum. Okay, das ist.
Jetzt sind wir beim Melonenreporting.
Ja, genau.
In Rot, außen grün. Genau.
Also da.
Und das ist das, was wir im PMO oder was ich persönlich gelernt habe, auch von
anderen Senior PMOS immer wieder Don't hesitate to eskalate.
Das ist nicht negativ behaftet.
Es ist eher, dass die Projektleiter dankbar dafür sind, wenn man sie pusht,
raised ist und sie jedes Mal challenged.
Ist das gerade ein Risiko?
Ja, Nein, Es gibt dafür klare Kriterien.
Raven geht seinen gewohnten Gang, seinen vorgesehenen Gang und alle
im Projekt profitieren davon. Ja.
Also haben wir drei coole Hacks mitgenommen.
Das erste wäre jetzt diese sofortige Transparenz schaffen mit dem Dashboard.
Die Synergien nutzen, auf andere zugehen.
Ja, und das dritte dann Don't hesitate to escalade.
Ich denke, das kann unseren Zuhörern viel Mehrwert bringen.
Dann vielen Dank, dass du da warst.
Ja, ich hoffe, dass es Mehrwert bringt.
Ich bedanke mich, dass ich da sein durfte.
Wer noch mehr von Oliver kennenlernen will, in den Shownotes dann auch seinen
Link zum Profil und natürlich auch jederzeit über
uns eine Kontaktaufnahme möglich.
Dann vielen Dank fürs da sein und bis zum nächsten Mal.
Danke.
Ich Danke.