So managst du große (IT-)Projekte erfolgreich | #ITProjektmanagement 💻

00:00:00: Hallo und herzlich willkommen zu einem neuen Innovate or Die podcast von Digital Compact.

00:00:12: Mein Name ist Jacob Schmarig und wie immer an meiner Seite der kompetente und viel geschätzte Boris Lockschild.

00:00:16: Hallo, Boris!

00:00:18: Und heute geht es um ein Thema das glaube ich sehr spannend ist weil es viele Schmerzpunkte bereithält nämlich sehr große Projekte richtig zurechtschneiden.

00:00:26: wir werden also darüber sprechen Wie sieht der günstigste Zuschnitt für ein großes Projekt aus?

00:00:31: Wie mixe ich eigentlich intern und extern richtig ab?

00:00:33: was gibt's bei dem Thema Accountability zu beachten und natürlich am Ende nach hinten raus?

00:00:37: typische Bruchstellen und Best Practices gefällt mir.

00:00:42: Fangen wir mal straight an!

00:00:43: Große Projekte ist ja immer ein Schmerz, zieht sich ewig wird teuer.

00:00:46: Ha, was ist so dein erster Einstiegspunkt wenn du dich mit sowas auseinandersetzt?

00:00:50: Genau also es gibt ja die Unterscheidung zwischen Projekten und Programmen oder Teilprojekte vielleicht in der Pyramide unten Teil-Projekte als Teile von einem Projekt.

00:01:00: Und dann sozusagen die Summe mehrere Projekte die dann inhaltlich thematisch irgendwie zusammen gehören an den man häufig Programm und umso größer ein Vorhaben wird egal ob das jetzt eine Produktentwicklung ist oder irgendeine Projekt Service Entwicklung oder vielleicht auch internationaler Rollout von irgendwas von der Commerce-Plattform, von einer App.

00:01:18: Von einer anderen Unternehmung umso größer die Wahrscheinlichkeit dass man in einem meistens dann doch schon komplizierten Programm landet mit eben vielen Partnern Abhängigkeiten, Dienstleister und Co.

00:01:27: Gut also Zuschnittlärmwehr ist quasi die erste wichtige Hausaufgabe.

00:01:31: hast du da so eine Art Best Practice oder ist jedes Projekt irgendwie ein Stück weit anders?

00:01:36: Man kann das vielleicht an den beiden Extremen so ein bisschen ablesen oder sich entlanghangeln.

00:01:40: Das eine extrem wäre natürlich, ich habe einen Projekt und ich schneide es maximal klein zu,

00:01:44: d.h.,

00:01:45: ich hab ganz viele einzelne Projekte darin.

00:01:47: Das können länderschnitt sein, das kann ein inhaltlicher Schnitt sein.

00:01:50: also im einem Projekt wird vielleicht irgendwas in Backend entwickelt, in dem anderen Projekt geht das Frontend.

00:01:54: Das kann technologischer Zuschnitt sein dass man sich überlegt okay ich habe verschiedene Skills.

00:01:59: ja hier wird mit einem Programmiersprache entwickelt, hier wird vielleicht mit einer Programmierssprache entwickelt Das kann ein regionaler Schnitt sein, dass man sagt okay ich habe jetzt Teams die an einem bestimmten Standort oder einem bestimmte Land sitzen und dann vielleicht über entsprechende geografische oder thematischen Kompetenzen verfügen.

00:02:14: Vielleicht in bestimmter Domänen einfach besser kennen irgendwie Rahmenrichtlinien sind aus einem entsprechenden Land.

00:02:20: Alternative ist natürlich, man versucht das eben nicht so fein zuzuschneiden und sich maximal viel in ein sehr großes Multi-Programm zu legen.

00:02:28: Das heißt also ich habe dann den Anspruch dass vielleicht eben zentral komplett führen zu können und versuche dann irgendwie eine kleinere Arbeitsgruppe das zu zerschneiden sind beides vor und nachteilig können wir gleich ein bisschen diskutieren.

00:02:38: Aber das sind so die beiden Extremer und in der Realität versucht man sich natürlich dann irgendwo in der Mitte einzupendeln.

00:02:43: Es gibt ganz, ganz viele Nachteile wenn man sehr klein schneidet und eben auch keine klare übergeordnete Führung und Aggregation von dem Thema hat.

00:02:52: Denn am Ende möchte man ja meistens deswegen heißt es ja auch Programm ein Resultat bekommen was inhaltlich zusammen gehört.

00:02:58: Wenn man sie zu klein schneidet und zunabhängig voneinander wird der Planungs- und Koordinierungs- und Durchführungsaufwand meistens sehr hoch und sehr teuer.

00:03:05: Gut, also was ist denn sonst so dein Best Practice?

00:03:07: Also wenn du sagst man kann es einerseits nach Technologie schneiden.

00:03:10: Nach Regionalität, nach Bereichsabteilungen... Hast du für dich so eine Daumenregel, was wann sozusagen zu bevorzugen ist?

00:03:18: Also man versucht normalerweise auch entsprechend gerade der ganzen Angelenenlehre die Teams natürlich maximal autonom zu halten.

00:03:24: Dass das die Teams eben zumindest innerhalb des Teams selbstständig an Themen arbeiten können und ebenso wenig Abhängigkeiten oder Drittabhängigkeiten haben wie nur möglich.

00:03:32: Umso größer die Abhängigkeit umso größere Abstimmungskoordinations Auffassung, so komplizierter wird es.

00:03:37: Das heißt meistens nicht so smart sich ein Team von zehn, zwölf Leuten überlegen, die mit vier verschiedenen Programmiersprachen drei Produkten arbeiten.

00:03:43: Es ist wahrscheinlich nicht so smart ein Team von zehn Leuten zu haben, die über drei Zeitzonen verteilt sind.

00:03:49: regional und zeitlich gesehen eben viel, viel abzustimmen haben.

00:03:52: Also das sind meistens so sehr natürliche Zuschnitte.

00:03:56: Meistens ergibt sich in der Realität natürlich auch dass die Leute auch irgendeine Form von Fachlichkeit haben.

00:03:59: Das bedeutet, dass ich Menschen habe, die sich vielleicht mit dem Frontend-System gut beschäftigen, mit der Webseite, mit dem Commerce System, mit einer Customer Facing App.

00:04:09: Da gibt es vielleicht Leute, die in den Backendsystemen zu Hause sind, ja?

00:04:12: Die das ERP, das PIM System gut kennen, gut beherrschen, das Ordermanage und Fulfillment ... die dort einfach Domain-Expertiese haben und eben auch entsprechend der ... ... entsprechende Geschäftsprozesse und Dialoge geben so gut beherrschen, dass sie diese auch inhaltlich ... ... dann voran treiben können.

00:04:29: Ja das ist jetzt unnötig zu vermischen ja ... ... führt meistens dazu, dass man eben nicht vorankommt.

00:04:36: Trotzdem versucht man hier gerade den energiellen Themen heute... ...auch eine End-to-End-Verantwortlichkeit zu haben also einen vertikalen Schnitt hatten wir ein paar anderen Folgen auch schon mal besprochen,... ...dass man eigentlich möchte, dass die Teams maximal autonomen sind, also ... ...das sie Wasserhommer, sie bauen ... vom Anforderungsdesign bis hin zum Release, dass er irgendwie selbst bekommt.

00:04:52: Wir haben

00:04:52: auch mal die nächste Frage gewesen.

00:04:54: also wenn du sagst das ist teilweise auch sehr stark davon abhängig wie so ein Projekt gebaut ist und das manchmal vielleicht eher die Abteilung wichtig ist manchmal eher die.

00:05:01: gibt es so einen Zentralen den du immer einen Hut aufsetzt oder versuchst du eher so Gremien zu bauen?

00:05:06: Wie gehst denn das an?

00:05:07: Also in der Realität, was man häufig macht ist natürlich dadurch... also wenn es ein Programm ist, das aus dann wie wir besprochen aus verschiedenen Projekten besteht.

00:05:15: Dann ist es meistens schon so dass es sehr sehr schwer ist dort einen inhaltlich zentralen Fan vorhin zu haben, der quasi alles versteht.

00:05:21: Meistens hat man dann eben sogenannte PMOs oder sozusagen wirklich Projektleiter die dafür Sorge tragen, dass mit dieser einzelnen Teilprojekte innerhalb des Gesamtprogramms vorangehen.

00:05:31: Das heißt also, dass die Abhängigkeiten eingehalten werden und das die Zeitachsen eingehalten wird, dass auch die Budgets und auch die Ressourcenallokationen zentral gesteuert wird.

00:05:40: Dafür gibt es eine Rolle, die ist dann weniger inhaltlich.

00:05:43: Das macht natürlich bei einem Programm, wenn ich irgendwie hundert, zwanzig Leute an so ein Programm habe, die daran arbeiten, vielleicht fünf bis sechs sieben Projekte organisiert hat man eben tatsächlich in der Realität meistens irgendeine PMO Funktion, die wie gesagt nicht ... dafür da, um inhaltlich zu steuern sondern einfach... ...um diesen Koordinierungsaufwand ein bisschen... ...zu vereinfachen abzunehmen oder zu organisieren.

00:06:02: Gut!

00:06:03: Dann kommt ja eine spannende andere Frage auf wie viel bild ich intern ab und wieviel extern?

00:06:08: Und dann kann man ja auf der einen Seite sagen wie steuer ich das?

00:06:10: aber vor allem möchte ich das also es kann ja am Ende des Tages aufwendiger sein vielleicht jemandem von extern rein zu holen.

00:06:16: dafür spart einem vielleicht an anderer Stelle Geld.

00:06:19: hast du da auch Best Practices wenn du das beides abmischst gegeneinander?

00:06:23: Die erste Frage ist ja immer, kann ich das zentral abbilden?

00:06:26: Also umso weniger... Auch hier gilt wieder die gleiche Regel.

00:06:28: Umso geringer die externen Abhängigkeit und so weniger Partnerpartei nicht in so ein Programmereinbische.

00:06:34: Um so einfacher wird es sich zu organisieren.

00:06:37: Das ist erst mal relativ klar Und liegt auch in der Natur der Sache, denn jeder Partner hat das jetzt ein Dienstleister ist, eine Agentur, ein Systemintegrator oder auch teilweise mehrere Vendoren.

00:06:49: Jeder Partner hat seine Arbeitsstandards.

00:06:51: Jeder partner hat irgendwie Richtlinien dazu wie Arbeit erledigt wird, wie die Prozesse aussehen selbst wenn man ähnlich arbeitet also zum Beispiel ähnlich agil arbeitet.

00:06:59: Jeder Partner hat seinen eigenen Tools.

00:07:01: Jeder parten hat seine eigenen Prozisse Security-Richtlinien und Co.

00:07:06: ja umso mehr Partner ich in so einem Gesamtprogramm mit einladen, daran mitzuwirken umso größer der Abstimmungsaufwand.

00:07:14: Denn eins ist ja auch klar man muss irgendeinen gemeinsamen Länder finden also gemeinsame Tools, gemeinsame Prozesse, gemeinsamer Art und Weise den Fortschritt zu reporten, zu visualisieren selbst so banale Dinge wie Urlaub Teilnahme irgendwie Urlaub von Projektteilnehmern zu planen ... Meetings zu organisieren.

00:07:31: Welche Videokonferenzplattform wird genutzt?

00:07:33: Welches Intente Wiki oder Ticket-System wird genutscht?

00:07:36: Das sind ja alle so ganz kleine Themen, die am Ende auch extrem viel alignment.

00:07:41: Aufwände bedeuten.

00:07:42: Sprich, wenn ich natürlich alles innerhalb einer einzigen Unternehmung habe wird wie gesagt die Organisations- und Alarmentaufwand geringer.

00:07:50: auf der anderen Seite koche ich natürlich auch ein Stück weit in meine eigene Suppe.

00:07:53: das heißt ich hab eben weniger Impulse, weniger neue Ideen, weniger Lernkurve.

00:07:58: jeder neue Partner, jeder neue Dienstleister, jeder neuen Beratern natürlich ein Stückweit auch Erfahrungen reinbringen vielleicht neue Tools, neue Perspektiven, neue Art und Weise anzugehen.

00:08:07: also das muss man so ein bisschen balancen.

00:08:10: Am Ende sind wir ein bisschen die Frage, was ist das übergeordnete Ziel des Programms?

00:08:14: Ist das Ziel des Programs einfach irgendwas zu liefern und idealerweise vielleicht in maximaler Geschwindigkeit oder einem sehr limitierten Budget.

00:08:21: Da wird man immer einen Setup wählen, was einfach extrem wenig overhead erzeugt oder es wird dann eben normal internisiert sein.

00:08:28: Das Ziel des Programm zu lernen, Kompetenz aufzubauen – also ganz häufig sieht man ja gerade jetzt in der Arbeit mit großen Konzernunternehmen, dass sie alle versuchen ihre Digitalkompetenz einfach natürlich gestreckt über die Zeit, das heißt vielleicht über den nächsten zwei drei Jahre im Gemeinsam mit Partnern bis sie da einfach auch die Quantität an Leuten und dann natürlich auch die Qualität haben.

00:08:50: Also dann ist das Ziel des Programms nicht nur eine App zu bauen oder nicht nur in einer Commerce-Plattform zu bauen, nicht nur ein großes Content-Portal zu bauen sondern natürlich auch Kompetenz aufzubauen, eine Organisationenstruktur zu schaffen, maximal viel Wissen aufzubauten.

00:09:02: Dann wird man wahrscheinlich einen Setup wählen was das ein bisschen besser ausbalanciert wenn man sagt okay Ich möchte Input haben, ich möchte Partner dabei haben.

00:09:10: Und ich verstehe auch dass diese Lernkurve und diese Art das Programm eben zu steuern auch ein Stück weit Zeit- und Geschwindigkeit kostet.

00:09:17: Es einfach liegt in der Natur der Sache und natürlich auch mehr Kosten oder Oberheadkosten verursacht.

00:09:23: aber das ist mir wert weil das quasi mehr als sich auszahlt über den Lernfortschritt der Organisation da vorne raus.

00:09:30: Na, ich wollte dich gerade fragen.

00:09:31: Wenn du sagst möglichst alles internalisieren was man internalisierend kann?

00:09:34: Was ist denn die KPI, die du optimierst?

00:09:36: Ist es quasi Geschwindigkeit?

00:09:37: Ist das Budget?

00:09:38: Ist da irgendwie Koordinationsaufwand?

00:09:41: Weil anderen für sich... Es kann ja auch manchmal genau wie Du sagst den externen Know-how zufluss geben.

00:09:45: Manchmal ist es doch schneller wenn man Sachen parallel extern bauen lässt während intern ein Team was anderes macht.

00:09:50: Auf was optimierest du, wenn Du intern und extern in großen Projekten abmischst?

00:09:54: Auch hier wir haben in einem oder zwei anderen Folgen glaube ich schon mal gesprochen.

00:09:56: Das Allerwichtigste ist wirklich auch Topmanagement oder Alignmentis.

00:10:00: bis jetzt zu den Eigentümern.

00:10:02: Es hilft nichts, wenn das Projekt irgendwie einen KPI hat und übergeordnet da anders drauf geschaut wird noch mal bei dem Beispiel zu bleiben von eben wenn ich einfach das Ziel habe, als Organisation eine digital Kompetenz aufzubauen.

00:10:14: Dann machen wir es mal ein bisschen konkreter.

00:10:16: Ich möchte eine Digital-Unit aufbauen.

00:10:17: hier hat mir vorgenommen in den nächsten drei Jahren möchte ich irgendwie hundert Leute aufbauern an einem bestimmten Standort und gemixt.

00:10:24: ja möchte sozusagen technische Fähigkeiten haben, möchte planerische Fährigkeiten haben möchte irgendwie BI Marketing Fähigkeit haben Und ich weiß ganz genau, dass wir dem zwei bis drei Jahre da und bis sich da eine Unit haben.

00:10:34: Zumindest die Schlagkraft hat im Kern meine digitalen Prozesse zu bauen, sich gerne verlängert und irgendwie auch nochmal anreichend extern aber im Kern selbstsufficient zu sein.

00:10:47: Das ist ein Ziel was allen klar ist.

00:10:49: Der Erfolg wird quasi jetzt mal nach vorne gespult dann daran gemessen... A. habe ich diese Kompetenz wirklich aufgebaut, hab' ich das hinbekommen?

00:10:57: Habe ich da die richtigen Leute in der richtigen Zahl mit den richtigen Skills?

00:11:00: und B., was ist sozusagen das Trainingsmaterial on the way?

00:11:05: Keiner oder selten wird man ja eine Möglichkeit bekommen einfach drei Jahre in Union zu bauen ohne irgendwelche Deliverables.

00:11:13: Das heißt, in der Realität würde es dann ganz häufig so sein dass dann eben vorgegeben wird, dass man dann oft im Weg dahin dann die zwei oder drei Projekte oder Teilprojekte zu liefern hat baut die App, rollt bitte die Comic-Plattform in dem Land aus.

00:11:27: Optimiert unser Orderful Filmensystem im Hintergrund.

00:11:31: Lass uns eine Anbindung zu diesem Zahlungsdienstleister

00:11:33: bauen.".

00:11:33: Also es wird ja diverse Projekte und Teilprojekte geben an denen man sich quasi beweisen kann, üben kann auch mal so tangible Results liefern können.

00:11:41: aber das wird dann der KPI sein wenn der K PI anders gesetzt ist.

00:11:44: Wenn der K P I ist wir wollen so schnell es geht eine Comics Plattform gebaut haben in den nächsten zwölf Monaten oder möchten so schnelles geht unsere Internet irgendwie umgestaltet haben brauchen, so schnell es geht.

00:11:53: Eine Kunden-Service App und das ist der KPI, irgendwie Bereitstellung von diesem konkreten Teilprojekt oder wir haben jetzt zehn Millionen Euro budgetiert und die wollen wir ausgeben für XYZ.

00:12:05: dann wird man eben anders rangehen.

00:12:07: Dann würde ich wahrscheinlich nicht anfangen ein Setup zu wählen was mit vielen Partnern verwoben ist wo viele Kompetenzen zu allein sind sondern würde versuchen entweder sehr viel selber zu machen oder mich maximal auf einen Partner zu kommenten.

00:12:20: Das ist ja auch nochmal eine Option, die häufig da ist, also die Zahl der Abhängigkeiten zu reduzieren indem man es nicht selber macht aber dann eben einen Generalunternehmer großen Dienstleister sucht er dann eben hier end-to-end diesen Service oder das Produkt hinstellt.

00:12:34: Gut verstanden!

00:12:35: Macht alles Sinn?

00:12:36: Gibt's denn bei großen Projekten was eigentlich die Dinge, die wir bisher besprochen haben, also Zuschnitt des Projektes und intern versus extern abmischen Unterschiede im Vergleich zu normalen Projekten?

00:12:46: Also würdest du bei kleineren oder vielleicht etwas mitteldimensionierten Projekte eine andere Externalisierung anstreben, als es bei einem großen Projekt tun würde.

00:12:53: Umso größer ein Projekt ist um so dringend die Wahrscheinlichkeit dass man eben die Skills komplett selber hat.

00:13:00: Bei dem kleinen Projekt also machen wir einen Beispiel wenn ich wirklich ein Projekt und typische Projektteam größe werden ja vielleicht irgendwas um die zehn zwölf Leute das ist etwas was man durchaus entweder selber hinbekommt oder mit einem einzigen Partner geschenkt bekommt.

00:13:14: So, plane ich jetzt einen globalen Rollout von irgendeiner riesigen Plattform in sieben Ländern mit ganz viel Frontend-Backendabhängigkeiten.

00:13:23: ganz viel Protestthemen, die noch irgendwie in der Organisation umgestellt oder nur aufgebaut werden müssen.

00:13:28: Ist die Wahrscheinlichkeit dass das eben ein Partner komplett covern kann ist dann natürlich auch geringer ja?

00:13:34: Oder es muss eben sehr großer Partner also so die Größe von so globalen sogenannten Systemintegratoren, die dann einfach zehntausend und hunderttausend teilweise vom Mitarbeiter haben.

00:13:43: Anführerweise das ist so ein bisschen leider das Problem, die jetzt zwar auf dem Papier diese Zahl der Leute haben aber am Ende sind die Leute trotzdem geschnitten auch wieder in kleine Delivery Units auch meistens regional.

00:13:56: Das heißt also die Wahrscheinlichkeit, dass das eben notwendiger wird mit zunehmender Größe des Programms steigt und wie gesagt System Integratoren können mir dazu auf dem Papier diese End-to-End Delivery Fähigkeit geben hat viele Vorteile.

00:14:10: ja denn die sind meistens in der Lage mir zumindest Vertraglich quasi alles abzunehmen, das heißt ich habe eine Vertragspartei.

00:14:17: Ich verhandle einmal SLRs, ich verhandel einmal Lieferprozesse und Timelines und Budgets meistens regional verteilten Delivery Units, so ein Programm oder einzelne Projektbestandteil des Programms eben mir hinstellen.

00:14:38: Wie gesagt macht es meistens nicht einfacher denn das ist dann eben tatsächlich nicht so in den seltensten Fällen so dass man auf einmal Hundert Leute irgendwie aus Hamburg dann auf meiner Initiative arbeiten sondern ich habe dann quasi einfach nur den Koordinations und den juristischen Aufwand dem nicht mehr in einer nicht mehr verteilt auf zehn Köpfe.

00:14:55: bei unten drunter in der Delivery ist es sozusagen das SI-Problem das eben wieder zum zu bauen und zusammenzustellen.

00:15:01: Gut,

00:15:02: riesiges Thema bei großen Projekten Accountability du hast ja eben auch schon erzählt dass man eigentlich immer end-to-end haben möchte also eine Person oder ein Personen Gremium was am besten von oben bis unten alles im Griff hat.

00:15:15: aber es gibt ja oft genug Situationen wo man vielleicht Fachexperten hat wo man eher möchte das Detail Bereiche davon nehmen.

00:15:21: wie ist das bei großen projekten?

00:15:23: Was ist eigentlich realistisch umsetzbar in Sachen Accountability und was empfiehlt sich vielleicht?

00:15:27: ... auch hier erst mal angefangen, weil mit den Extrempositionen.

00:15:33: Was ist das Ideale?

00:15:34: Jeder Kunde möchte natürlich idealerweise ... ... Entwender-Contability haben.

00:15:38: Das heißt du möchtest eigentlich ruhig schlafen, darum ... ... möchtes komplett sicher sein dass es irgendwie diesen einen ... ... Joel gibt dem ich an die Hörner fassen kann.

00:15:46: ja wenn das irgendwie nicht funktioniert... ... der zu jeder Zeit den vollen Überblick hat über alle Bestandteile.

00:15:52: Der zu jederzeit alle Partner, Dienstleister und involvierter auch entsprechend ... ... pushen kann kann und da vorne treiben kann, der einen Wundersack hat auch an Ressourcen um das auszubalancieren.

00:16:04: Wenn in dem Einteilprojekt Dinge nicht vorangehen dann können Leute umschichten von links nach rechts und der am Ende sozusagen für alles gerade steht ja wenn es nicht funktioniert den du bestrafen kannst, wenn das nicht läuft und co.

00:16:15: Das gibt es das kann man so machen hat natürlich sehr viele Nachteile.

00:16:20: klar.

00:16:21: die Vorteile sind erstmal klar die Nachteilen diejenigen, die in der Lage sind oder auch bereit sind, auch dieses Maß an Verantwortung zu übernehmen und auch zu tragen lassen sich bezahlen.

00:16:31: Das ist glaube ich relativ klar das es am Ende eine Versicherung und auch ein nicht zu unterschätzender personeller Koordinations- und Steuerungsaufwand.

00:16:39: also dass heißt der Partner wird das immer einpreisen.

00:16:42: Der Partner hat das Risiko einpreisten, bin natürlich auch die Steuerungsressourcen, die dafür notwendig sind einpreißen.

00:16:49: was aber vielleicht noch am schwersten Weg bei sowas ist ist, dass Accountability und Empowerment immer Hand in Hand gehen.

00:16:57: Das glaube ich hatte ich in einem anderen Podcast auch schon mal gesagt das heißt jemand der Accountability übernimmt wird immer das Empowerement fordern.

00:17:04: was heißt das bedeutet nichts anderes als wenn ich verantwortlich sein soll dafür dass das Programm im Time, in Budget, in Quality, in Scope geliefert wird.

00:17:12: dann brauche ich auch vollen Durchgriff.

00:17:13: das heißt ich muss eben eine Lage sein komplett Dinge so auch bauen zu können, wie ich das für richtig halte.

00:17:20: Ich muss vollen Durchgriff haben über alle Partner-Dienstleister.

00:17:23: Ich muß weisungsbefugt sein und im Zweifel auch intern mitarbeiten.

00:17:26: gehen wir beweisungsbefuht sein.

00:17:27: Das heißt also, ich muss in der Lage sein, auch da eine eigene Leute zu steuern.

00:17:30: Denn wie soll ich denn sonst die Verantwortung tragen?

00:17:32: Wenn jeder arbeitet, wie er will, wann er will tut was er will und ich immer wieder irgendwie in Diskussionen rein laufe weil der Partner nicht gerade ansteuere mir aber sagt, mit ihm war ne ganz andere Timeline verabredet oder es ist schon kein Budget mehr auf den wenn man den arbeitet oder irgendwie wurde ganz andere Art und Weise besprochen, die Dinge zu erledigen.

00:17:50: Und das kann eine nicht so unterschätzende Downside sein gerade eben im Hinblick auf das was wir vorher besprochen haben.

00:17:56: Wenn mein Anspruch ist digital Kompetenz aufzubauen nach vorne raus also wirklich auch Ownership zu haben ja dann tue ich damit erstmal nichts anderes als genau das abzugeben.

00:18:04: Das heißt ich baue überhaupt keine Ownerships auf Ich handele, ich traite sozusagen dieses...ich kann durchschlafen.

00:18:10: es gibt jemanden dem mich an die Hörner fassen kann gegen ein komplett mehr oder weniger outgesourztes Blackbox-Modell, bei dem ich mich zurücklehne.

00:18:19: Mehr oder weniger entspannt und darauf warte dass irgendwie Blackbox geliefert wird.

00:18:22: aber das ist natürlich auch ein Stück weit das Antimodell von modernen, zumindest digital Projekten.

00:18:29: Und nicht nur als Antimodel sondern es führt auch... Das hat auch eine ganz gefährliche Nebenkomponente nämlich sogenannte Lock Endeffekte.

00:18:37: Das heißt also diejenige den du, sind wir so ein bisschen die andere Seite der Medaille, die man sich diese Art von Power ...gebe, der hat sie dann auch.

00:18:47: Und dann habe ich ihn ein Stück weit auch... ...mich selbst in so einen goldenen Käfig vielleicht gesetzt und kommt dann eben nicht mehr raus.

00:18:53: Da ist sehr viel Projekt know-how, sehr viel Kontext, sehr viele Detailwissen.

00:18:59: was eben bei einem Partner da liegt.

00:19:00: Das muss nicht schlecht sein, es gibt ja sehr gute, sehr fruchtvolle, sehr langjährige Partnerschaften.

00:19:05: also ich will auch gar keinen Fall da die sozusagen dieses Modell jetzt irgendwie schlecht machen.

00:19:08: aber das ist einfach ein Trade-off.

00:19:09: dem muss man sich... Man muss sich dessen bewusst sein und sich dann entweder sehr aktiv dafür entscheiden Aber zu hoffen, dass man ein internes Modell macht bei dem man ganz viel Kompetenz aufbaut während man das komplett vom Hof geschoben hat und dann auch noch für einen günstigen Preis.

00:19:23: Das wird es in der Realität nicht geben.

00:19:25: Also das ist etwas, was man sehr stark schauen muss ja und sich entscheiden muss, ob man das Modell machen oder eben das Gegenmodell davon.

00:19:31: Aber was du gerade beschrieben hast, mit Empowerment und Accountability lässt sich das in großen Projekten denn eigentlich wirklich durchgreifend realisieren?

00:19:37: Weil wenn die so groß sind wie wir sie jetzt eigentlich mal also der Wage geblieben ist.

00:19:41: Was heißt für uns groß?

00:19:42: aber wenn da viele Abteilungen daran beteiligt sind es unterschiedliche Deadlines gibt Projekttöpfe usw.

00:19:47: Und sofort dann wird das doch kaum realisierbar sein in der Regel.

00:19:50: oder

00:19:51: Ja, das ist auch der Grund warum wir glaube ich alle jeden Tag in der Presse lesen.

00:19:55: Warum solche großen Projekte irgendwie total aus dem Ruder laufen, budgetmäßig und time-land technisch oder eben nicht aus einem Ruder laufen, budgetmäßig aber dann irgendein Quatschkredi vertwert gibt ja viele Öffentlichkeits-Türksame IT-Projekte so in den letzten paar Monate aus unserem Salaumfeld.

00:20:09: also es ist schwierig wobei hier muss ich sozusagen die Lanze berechnen weil für die ganzen IT-Kollegen es ist grundsätzlich schwieriger.

00:20:16: das hat jetzt nichts damit zu tun ob jetzt ein Partner da irgendwie gut ist oder nicht.

00:20:19: ein super schweres Thema wie alles im Leben.

00:20:23: Umso mehr Köche damit kochen, umso mehr Leute da rumlaufen, um so heterogener die Landschaft, Technologie mehr Schnittstellen... Also es ist schon breit ja.

00:20:32: aber genau deswegen versucht man das eben auch anders zu schneiden und eben im Zweifel irgendwie eine Balance zu finden, die zum Beispiel aussehen kann, dass man sagt okay die zentrale Steuerungs- und Koordinationskompetenz Die möchte ich gar nicht zukaufen.

00:20:47: Das heißt also, das Risiko, das nehme ich als Unternehmen selber.

00:20:50: Also mir ist klar, dass sich eben nicht mehr... diesen einen Partner habe, der für alles gerade also den Generalbauunternehmen habe ich nicht.

00:20:57: Sondern ich bin das jetzt selber.

00:20:58: dafür weiß ich aber auch genau wie das Haus gebaut wird und was dort los ist und welche Dinge dort verbaut sind und wieso welche Entscheidungen dort auch underway getroffen worden sind?

00:21:06: Ich nehme damit natürlich auch die Verantwortung auf mich diese einzelnen Gewerke zu koordinieren.

00:21:10: Das heißt ich habe dann eben die drei vier Partner die dort unterwegs sind.

00:21:13: Ich muss dafür Sorge tragen dass die Arbeitsweisen Methoden Inhalte Scope Timelines Budgets davon abgestimmt sind.

00:21:19: Es ist eine wichtige Kompetenz ... fairerweise aber eine, die ich sowieso brauche.

00:21:24: Also das ist ja keine Frage von... also wenn ich nochmal, wenn ich jetzt nicht nur vorhabe, eine Webseite zu bauen und danach mich nie wieder mit digital zu beschäftigen, ... ... brauch' ich so oder so?

00:21:32: Ja denn die Annahme nach vorne raus, dass Projekte weniger komplex werden oder ich weniger Technologie haben werde, weniger technologische Frameworks, weniger ... ... technologischer Technologie-Experten im Unternehmen.

00:21:41: Die ist ja glaube ich nicht richtig.

00:21:43: Das heißt es ist ja sozusagen der natürliche Entwicklung.

00:21:45: dann fange ich lieber jetzt damit an und nutze auch die Chance den was auch klares is'.

00:21:50: ... in ein bestehendes Projekt oder Programm einzugreifen, also inhaltlich einzutauchen und dann Know-how zu übernehmen.

00:21:56: Das ist fast unmöglich!

00:21:58: Dafür werden auf Tagesbasis, auf Wochenbasis so viele tausende Mikroentscheidungen getroffen... Also eigentlich ist der beste Zeitpunkt für mich als Unternehmen genau in so einem Neuaufbau, Replatforming, Neuausbau von dem Projekt und dem Programm wo eben genau die Dinge neu entstehen.

00:22:13: Da da ist quasi grüne Wiese und damit reinzugehen Ich kann ja ein Hybrid-Modell fahren, in dem ich zum Beispiel sage... ...ich bin auch im OrgChart im Lead als Unternehmen.

00:22:25: Trotzdem habe ich aber Partner vielleicht eher beratender Natur die bei MySide sind, die mir helfen und mir geil insgeben.

00:22:31: Die mir sozusagen Frameworks geben, wie ich Ressourcen zu planen habe, wie eine Timeline zu organisieren ist,... ...wie ich ganz Diagramme zeichne, wie mich Abhängigkeit und kritische Fahre.

00:22:41: bedenke welche coolen Tools es gibt.

00:22:43: Das kann man ja alles machen, ohne aber zu sagen ich bin aber dafür nicht verantwortlich.

00:22:46: Sondern das macht jetzt der Joel.

00:22:48: Ich kann mir komplett selber die Accountability nehmen und mich aber sozusagen links und rechts schon auch mit Partnern umgeben, die dann das Know-how transferieren.

00:22:57: Das ist auch gut weil ich natürlich als Auftraggeber, als Projektinitiator oder Programminitiato immer eine bessere Durchgriff habe.

00:23:05: Ja es ist ja eine Sache.

00:23:06: Als wenn du drei Partner managest, die alle für dich arbeiten?

00:23:09: Oder einen vierten diesen Aufwand rausgibt, der drei Partner zu managen hat.

00:23:13: Also da hast du dann immer Dinge wo du nicht hundert Prozent reingegucken kannst ja von irgendwie laxender Steuerung bis hin zur fettern Wirtschaft was nicht alles gibt.

00:23:21: also ist es immer leichter selber die Hand rüberzuhalten und das ist auch immer effizienter.

00:23:26: Gut, abschließendes Thema der Classic.

00:23:28: Was sind so typische Solbruchstellen?

00:23:30: Woran scheitern große Projekte klassischerweise?

00:23:32: Also Accountability ist wahrscheinlich ein großes Thema was wir schon hatten die Abmischung intern extern vielleicht auch.

00:23:37: und Zuschnitt.

00:23:38: gibt es sonst irgendwie typische Classics wo du sagst dass sich eigentlich immer wieder in der Praxis daran scheitert?

00:23:43: Ja also was super was mittlerweile sehr witzig ist das viele Unternehmen gelernt haben oder beigebracht bekommen haben wie nie die einzelnen Projekt- oder Typeprojektbausteine mehr oder weniger agil und effizient.

00:23:57: Und sozusagen nach moderner, nach modernen Best Practices zu führen sind.

00:24:00: Also wenn wir dann reinzooms in die einzelne Bausteine und sagst okay wie arbeitet das Team was die App baut?

00:24:06: Oder wie arbeitet jetzt das Team, was hier diesen Kundenprozess baut.

00:24:09: Das sieht als erst mal gar nicht so schlecht aus!

00:24:12: Das Hauptproblem entsteht eigentlich immer mittlerweile im Querschnitt in den Querschnitzfunktionen.

00:24:17: Am Ende möchte ich ja nicht die Summe von zehn topoptimierten Silos haben, sondern ich möchte eine Lage sein end-to-end ne Hose in den Warenkorb zu legen und die irgendwie zu kaufen oder ne Banane in den wahren Korb zu lehnen und die zu kaufen ein Versicherungsprodukt konfigurieren und das dann bestellen.

00:24:32: In der kundenzentrischen Welt ist es die Aufgabe des Programms oder des Projekts.

00:24:36: Und dort gibt's natürlich ganz viele Systeme und Leute und Abteilungen was eben momentan ganz klar ist es eben überall da wo du eigentlich so einen horizontalen Schnitt durch die einzelnen Silos, verticalen Teams, Projektteams you name it machst.

00:24:50: Das sind dann so Themen wie zum Beispiel Testing.

00:24:53: also wie organisiere ich eine übergreifende Teststrategie zwischen diesen einzelnen Silos sodass sich wirklich auch end-to-end und auch Integrationstests habe und wirklich sehen kann ja wie landet der Schuh?

00:25:03: Ja, wie kommt Produktdaten in das System?

00:25:06: Wie sucht ein Kunde.

00:25:08: Wie legt er das in den Warenkorb?

00:25:09: Wie kauft der es?

00:25:09: Wir landen jetzt beim Payment und wir landen uns beim Fulfillement.

00:25:12: Wir landens beim Customer Service.

00:25:14: einfach einmal diesen horizontalen Schnitt durch eben diese fünf, sechs, sieben Teilprojekte.

00:25:18: Themen wie zum Beispiel Business Readiness ganz klar ja ich habe ja ganz viele Themen die nicht so feature sind sondern Ich muss einfach Daten anlegen.

00:25:25: Ich muss mal irgendwie E-Mail Templates befüllen.

00:25:29: Provider konfigurieren.

00:25:30: Ich muss gleich irgendwie Content-Seiten oder Produktinformationsseiten pflegen, also klassisch Business Readiness.

00:25:35: Themen wo nicht die Entwickler, die Entwicklern haben alles schön hingekotet und Feature funktioniert mit Dummy-Daten wunderbar und Lore Im Y steht auch überall drin und Produkt XYZ für neunneunzig, neuneinneuen Euro liegt auch im Warenkorb.

00:25:50: ja aber irgendwie ist das nur nicht so dass du sagst jetzt kann der Entuser mit drauf, ja?

00:25:56: Also Testing, Business Readliness, also Daten weil das Dritte was daraus kommt, also wirklich Stammdaten, Content-Daten, Produktstammdate, Kundendaten.

00:26:06: Migration von irgendwie aus Altsystemen, alte Passwörter, alte Userdaten... Das sind so alle Sachen die liegen quasi in niemandes Zuständigkeit in einem stark geständenen Programm, denn jeder baut seine Funktionalität und stellt seine App hin Aber am Ende funktioniert es dann trotzdem.

00:26:22: Dokumentation, so dass man am Ende hinterher, wenn die Plattform da steht und vielleicht die Initialen Teams auch nicht mehr auf dem Programm sind, wie stelle ich sicher das sich jemand neu ist damit zurechtfindet der das irgendwie übernehmen kann?

00:26:34: Betrieb also Infrastruktur, Clouds, Skalierung, Deployment wir kümmern sich darum.

00:26:39: Also das sind so Dinge, die in der Praxis eben entsprechend Aufwand brauchen.

00:26:44: und auch hier zurückzunehmen was wir vorhin besprochen haben umso feiner geschnitten die Teams.

00:26:48: Ich muss immer diese Balance finden zwischen Ich kann fein schneiden, dann habe ich auch Tage selbstständige eigenverantwortliche Teams erhöhen damit aber immer diesen Querschnittsaufwand.

00:26:58: Und ich muss ein Programm immer so ausbalancieren dass sich die Dinge irgendwie in den Waage halten und dem nicht dazu führen das ich jetzt sieben, dreißig kleine Teams unten drunter habe Aber der Koordinations- und Overhead Aufwand budgetär und ressourcenmäßig diese ganzen Vorteile wieder sofort aufgefressen hat.

00:27:15: einen riesen Querschnittslayer auf einem Team aus zwei Projekten in nem kleinen Programm legen, möchte ich auch nicht.

00:27:20: Ich muss uns entsprechend smart und deswegen wieder zurück zum Initialpunkt.

00:27:24: Smart schneiden initial, sauber ausbalancieren und mir immer die Frage stellen, wofür will ich verantwortlich sein?

00:27:31: Und dann eben diesen Aufwand zwischen den einzelnen Projekte und dem Programm so austarieren dass er in Summe immer noch effizient ist und ihm nicht mehr arbeitvorsacht als er ertragt bringt.

00:27:42: Gut, also Querschnittslogik plus irgendwie sinnhaftes Austarieren und dann so eine gewisse, ich sage mal Hygiene, Prozesshygiene für die du gerade besprochen hast.

00:27:49: Wie kriegst du es hin?

00:27:49: Dass wenn Themen anfallen, die jetzt auf niemandem das Tisch liegen als was du gerade beschrieben hast zum Beispiel Testding oder Dokumentation dass da sich jemand verantwortlich fühlt ist das dann wieder so ne Frage von Accountability nach oben hin?

00:28:02: oder ist es ne Kulturfrage?

00:28:03: Hast du da irgendwie für dich etwas gefunden?

00:28:04: Also es ist auf jeden Fall eine Frage von... Ganz ein Simpler, wo du musst erstmal jemanden verantwortlich machen dafür.

00:28:09: A sind mittlerweile oder heutzutage die sie los natürlich selber alle für sich selbst verantwortliche inkrementell, sich selbst zu testen und sich selbst optimieren.

00:28:17: aber dieser übergeordnete Aufwand den du immer hast also in irgendeinem Prozess verantwortlichen zu haben das macht man meistens eben auf Ebene des sogenannten Programmanagement da einmal In zwei Wochen einmal in einem Monat Leute hast die dann ein bisschen wie so eine Demokratie, die dann sozusagen die Repräsentanten der einzelnen Projekte oder der Teilprojekte sind.

00:28:35: Die dann zusammenkommen und die dann entsprechend allein werden.

00:28:38: Also wie sieht die Timeline aus?

00:28:40: Wie sieht die Ressourceverteilung aus?

00:28:42: Das ist eben klassische Aufgabe des Programmmanagers nicht... Die einzelnen Silos optimieren und sagen, der Joel hat in seinem Team zehn Leute.

00:28:49: Boris hat acht Leute.

00:28:51: So, Joel kommt ein bisschen besser voran.

00:28:52: Boris ist ein bisschen schlechter.

00:28:53: jetzt nehmen wir vielleicht mal zwei Leute von Joel zu Boris ins Team.

00:28:56: ja gucken dass wir das mal ein bisschen austarrieren Das wird ja keiner von uns beiden individuell entscheiden können.

00:29:00: wieder du willst Ressourcen abgeben noch ich kann ressourcen von dir klauen Das muss eben ein Programmmanager beschließen.

00:29:06: oder auch Abhängigkeit in Zusammenhalt zu.

00:29:08: Boros kommt vielleicht nicht so schnell voran bei dem Teil, das ist aber für den nächsten Sprint bei Joël wichtig weil sonst kann er nicht starten.

00:29:13: Es lässt uns mal entscheiden dass wir die Aufgaben entsprechend tauschen oder wir merken dass wir hier gerade ganz viel schwarze oder blindspots haben weil die beide mit zwei verschiedenen Tools arbeiten und eben nicht die Übersicht habe über den Fortschritt.

00:29:28: Lass uns vielleicht auf einen Tool wechseln.

00:29:29: Das sind so Dinge, die man ins Programmmanagement legt.

00:29:31: Und dazu gehören dann eben auch solche Dinge wie übergeordnete Teststrategie, Business Readiness Checklisten, Infrastruktur, Deployment Tasks und Co.

00:29:40: Superb!

00:29:41: Also... Ich glaube, es war ein guter spannender Ritt.

00:29:43: Ich hoffe, dass jetzt viel mehr große Projekte gut laufen, nachdem man dir zugehört hat.

00:29:46: Hast du ein bisschen aktuellen Aufhänger gehabt?

00:29:48: Also hast du's jetzt öfters mal gehabt, dass du gesehen hast, okay, große Projkte bekunden von euch gegen die Wand also ist das nach wie vor was einfach zur Tagespraxis gehört?

00:29:56: Ja,

00:29:56: so ging die Wand nicht.

00:29:57: aber was ich natürlich schon sehe ist also armloserweise mit steigender Größe von uns selbst und jetzt natürlich auch mit zunehmender... Internationalisierung, wir machen sehr viele in den USA, UK Nordics und irgendwie anderen Ländern.

00:30:09: Merkt man natürlich schon dass auch die Projekte oder die Programme dann eben größer internationaler werden.

00:30:13: mehr Business Units um ein größerer Scope, größere Dimensionen ja und das dann natürlich eben auch die Unternehmen selber natürlich auch noch größer werden.

00:30:22: und da merkt man eben schon was da so das gemeinsame Pattern momentan ist.

00:30:26: für Success- oder Failure.

00:30:27: Ja und das finde ich super spannend zu sehen dass viele in dem einzelnen Teilprojekt bereichen tatsächlich gar nicht super schlecht organisiert sind.

00:30:34: Das kann man schon reinschauen und hier und da ein Kriminell verbessern, aber im Wesentlichen sind die Projekte okay.

00:30:41: wo es tatsächlich total krenkelt und harpert oder wo einfach viel Risk drin liegt ist eben auf der Programmmanagement Seite.

00:30:48: und ja umso größer und umso heterogener, umso verteilter, um so mehr Partner-Dienstleister weniger man selber Kompetenz hat umso umso grösser die risk flex.

00:30:57: das heißt nicht dass es nicht funktioniert aber es ist auf jeden Fall dann so ein Thema weil ... fairerweise aus Unternehmenssicht ist es da meistens so, dass natürlich die Unternehmen wollen einfach dieses fertige Resultat.

00:31:08: Aber dieser Link zwischen ich möchte das fertige Ergebnis und ich habe jetzt auf einzelnen Eben eigentlich alles gut hingestellt.

00:31:14: Also diese Klammer, die sozusagen fehlt dies nicht allen ersichtlich ja... Und ich glaube da ist viel zu tun noch!

00:31:19: Gut, liebe Hörerinnen und Hörern wir freuen uns natürlich auch immer über eure Anregung.

00:31:22: Wenn ihr noch was beizusteuern habt schreibt uns doch gerne zum Beispiel auf LinkedIn.

00:31:26: also Boris ist dort als Boris Lockshun unterwegs freut sich glaube ich über Follower Vernetzung und Co.

00:31:31: Und ich auch unter Joel Kaczmarek.

00:31:32: lieber Boris vielen vielen Dank.

00:31:34: und ja Ich bin mal gespannt was ich noch in den nächsten... Also bestimmt machen wir ein Update!

00:31:37: Könnte mir vorstellen dass das irgendwann nochmal auf kommt.

00:31:39: Das Thema neue Learnings zum Thema Projekte Managern die über das Größerte generiert sind.

00:31:44: In diesem Sinne danke dir und gutes Gelingen.

00:31:46: Danke

00:31:46: Joel Ciao.