So managst du große (IT-)Projekte erfolgreich

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate-or-Die-Podcast von digital kompakt. Mein Name ist Joel Kaczmarek und wie immer an meiner Seite der kompetente und vielgeschätzte Boris Lockschin.

Boris Lokschin: Hallo Boris. Hallo Joel.

Joel Kaczmarek: Gut, und heute geht es um ein Thema, das glaube ich sehr, sehr spannend ist, weil es viele Schmerzpunkte bereithält, nämlich sehr große Projekte richtig zurechtschneiden. Wir werden also darüber sprechen, wie sieht der günstigste Zuschnitt für ein großes Projekt aus? Wie mixe ich eigentlich intern und extern richtig ab? Was gibt es beim Thema Accountability zu beachten? Und natürlich am Ende nach hinten raus typische Bruchstellen und Best Practices. Guck mal, gutes Programm heute, Boris, gefällt mir. Fangen wir mal straight an. Große Projekte, ist ja immer ein Schmerz, zieht sich ewig, wird teuer. Was ist so dein erster Einstiegspunkt, wenn du dich mit sowas auseinandersetzt?

Boris Lokschin: Genau, also es gibt ja die Unterscheidung zwischen Projekten und Programmen oder Teilprojekten, vielleicht so in der Pyramide unten Teilprojekte als eben Teile von einem Projekt und dann sozusagen die Summe mehrerer Projekte, die dann inhaltlich, thematisch irgendwie zusammengehören, nennt man häufig Programm. Und um so Umso größer ein Vorhaben wird, egal ob das jetzt eine Produktentwicklung ist oder irgendeine Projektserviceentwicklung oder vielleicht auch irgendwie internationaler Rollout von irgendwas, von einer Commerce-Plattform, von einer App, von irgendeiner anderen Unternehmung, umso größer die Wahrscheinlichkeit, dass man eben in einem meistens dann doch schon komplizierten Programm landet mit eben vielen Partnern, Abhängigkeiten, Dienstleistern und Co.

Joel Kaczmarek: Gut, also Zuschnittlern wäre jetzt quasi die erste wichtige Hausaufgabe. Hast du da so eine Art Best Practice oder ist jedes Projekt irgendwie ein Stück weit anders?

Boris Lokschin: Man kann das vielleicht an den beiden Extremen so ein bisschen ablesen oder sich entlanghangeln. Also das eine Extrem wäre natürlich, ich habe ein Projekt und ich schneide das eben maximal klein zu. Das heißt, ich habe ganz, ganz viele einzelne Projekte darin. Das kann ein Länderschnitt sein, das kann ein inhaltlicher Schnitt sein. Also in einem Projekt wird vielleicht irgendwas im Backend entwickelt, in einem anderen Projekt irgendwie das Frontend. Das kann ein technologischer Zuschnitt sein, dass man sich überlegt, okay, ich habe verschiedene Skills, ja, hier wird mit der einen Programmiersprache entwickelt, hier wird vielleicht mit einer anderen Programmiersprache entwickelt. Das kann ein regionaler Schnitt sein, dass man sagt, okay, ich habe jetzt Teams, die an einem bestimmten Standort oder einem bestimmten Land sitzen und dann vielleicht über entsprechende geografische oder thematische Kompetenzen verfügen, vielleicht ein bestimmter Domain einfach besser kennen, irgendwie Rahmenrichtlinien sind aus einem entsprechenden Land. Alternative ist natürlich, man versucht das eben nicht so fein zuzuschneiden und sich eben maximal viel in ein sehr, sehr großes Multiprogramm zu legen. Das heißt also, ich habe dann den Anspruch, das vielleicht eben zentral komplett führen zu können und versuche dann irgendwie in kleinere Arbeitsgruppen das zu zerschneiden. Das sind beides Vor- und Nachteile, können wir gleich ein bisschen diskutieren, aber das sind so die beiden Extreme. Und in der Realität versucht man sich natürlich dann irgendwo in der Mitte einzupendeln. Es gibt ganz, ganz viele Nachteile, wenn man sehr, sehr klein schneidet und dann eben auch keine klare übergeordnete Führung und Aggregation von den Themen hat. Denn am Ende möchte man ja meistens, deswegen heißt es ja auch Programm, auch ein Resultat bekommen, was inhaltlich zusammengehört. Wenn man es eben zu klein schneidet und zu unabhängig voneinander, dann wird eben der Planungs- und Koordinierungs- und Durchführungsaufwand meistens sehr, sehr hoch und sehr teuer.

Joel Kaczmarek: Gut, also was ist denn sonst so dein Best Practice? Also wenn du sagst, man kann es einerseits nach Technologie schneiden, nach Regionalität, nach Bereichsabteilungen. Hast du für dich so eine Daumenregel, was wann sozusagen zu bevorzugen ist?

Boris Lokschin: Also man versucht normalerweise auch entsprechend gerade der ganzen agilen Lehre, die Teams natürlich maximal autonom abzubauen. zu halten, dass die Teams eben zumindest innerhalb des Teams selbstständig an Themen arbeiten können und eben so wenig Abhängigkeiten und Drittabhängigkeiten haben wie nur möglich. Umso größer die Abhängigkeiten, umso größer der Abstimmungs- und Koordinationsaufwand, umso komplizierter wird es. Das heißt meistens nicht so smart, sich ein Team von zehn, zwölf Leuten zu überlegen, die mit vier verschiedenen Programmiersprachen an drei Produkten arbeiten. Es ist wahrscheinlich nicht so smart, ein Team von zehn Leuten zu haben, die über drei Zeitzonen verteilt sind und auch regional und zeitlich gesehen eben viel, viel abzustimmen haben. Also das sind meistens so sehr natürliche Zuschnitte. Meistens ergibt sich in der Realität natürlich auch, dass die Leute auch irgendeine Form von Fachlichkeit haben. Das bedeutet, dass ich Menschen habe, die sich vielleicht mit dem Frontend-System gut beschäftigen, mit der Webseite, mit dem Commerce-System, mit der Customer-Facing-App. Dann gibt es vielleicht Leute, die eher in dem Backend-System zu Hause sind, die das ERP, das PIM-System gut kennen, gut beherrschen, das Order-Management-Fulfillment-System. Also die dort einfach Domain-Expertise haben und eben auch entsprechend die Geschäftsprozesse und die Logik eben so gut beherrschen, dass sie diese auch inhaltlich dann vorantreiben können. Das jetzt unnötig zu vermischen, führt meistens dazu, dass man eben nicht vorankommt. Trotzdem versucht man ja gerade in agilen Themen ja heute auch eine End-to-End-Verantwortlichkeit zu haben, also einen vertikalen Schnitt, hatten wir ja in ein paar anderen Folgen auch schon mal besprochen, dass man eigentlich möchte, dass die Teams maximal autonom sind, also dass sie, was auch immer sie bauen, vom Anforderungsdesign bis hin zum Release, ja, dass irgendwie selbstständig ist.

Joel Kaczmarek: Wäre aber auch meine nächste Frage gewesen. Also wenn du sagst, das ist teilweise auch sehr stark davon abhängig, wie so ein Projekt gebaut ist und dass manchmal vielleicht eher die Abteilung wichtig ist, manchmal eher die. Gibt es so einen Zentralen, dem du immer einen Hut aufsetzt oder versuchst du eher so Gremien zu bauen? Wie gehst du das an?

Boris Lokschin: Also in der Realität, was man häufig macht, ist natürlich dadurch, also wenn es ein Programm ist, was aus verschiedenen Projekten besteht, dann ist es meistens schon so, dass es sehr, sehr schwer ist, dort einen inhaltlich zentralen Verantwortlichen zu haben, der quasi alles versteht. Meistens hat man dann eben sogenannte PMOs oder sozusagen wirklich Projektleiter, die dafür Sorge tragen, dass eben diese einzelnen Teilprojekte innerhalb des Gesamtprogramms vorangehen. Das heißt also, dass die Abhängigkeiten eingehalten werden, dass die Zeitachsen eingehalten werden, dass auch die Budgets und auch die Ressourcenallokation zentral gesteuert wird. Dafür gibt es dann irgendeine Rolle, die ist dann weniger inhaltlich. Das macht natürlich dann bei einem Programm, wenn ich irgendwie 100, 200 Leute an so einem Programm habe, die daran arbeiten, in vielleicht 5, 6, 7 Projekten organisiert, hat man eben tatsächlich in der Realität meistens irgendeine PMO-Funktion. Die ist, wie gesagt, nicht dafür da, um inhaltlich zu steuern, sondern einfach, um diesen Koordinierungsaufwand ein bisschen zu vereinfachen, abzunehmen oder zu organisieren.

Joel Kaczmarek: Gut, dann kommt ja eine spannende andere Frage auf, wie viel bilde ich intern ab und wie viel extern? Und dann kann man ja auf der einen Seite sagen, wie steuere ich das, aber vor allem möchte ich das? Also es kann ja am Ende des Tages aufwendiger sein, vielleicht jemanden von extern reinzuholen, dafür spart es einem vielleicht an anderer Stelle Geld. Hast du da auch Best Practices, wenn du das beides abmischst gegeneinander?

Boris Lokschin: Genau, also die erste Frage ist ja immer, kann ich das zentral abbilden? Also umso weniger, auch hier gilt wieder die gleiche Regel, umso geringer die externe Abhängigkeit, umso weniger Partner, Parteien ich in so ein Programm reinmische, umso einfacher wird es, sich zu organisieren. Das ist erstmal relativ relativ klar und liegt auch in der Natur der Sache, denn jeder Partner, egal ob das jetzt ein Dienstleister ist, eine Agentur, ein Systemintegrator oder auch irgendwie teilweise mehrere Vendoren, jeder Partner hat seine Arbeitsstandards. 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. Jeder Partner hat seine eigenen Tools, jeder Partner hat seine eigenen Prozesse, Security, Richtlinien und Co., ja. Umso mehr Partner ich in so einem Gesamtprogramm mit einlade, daran mitzuwirken, umso größer der Abstimmungsaufwand, denn eins ist ja auch klar, man muss irgendeinen gemeinsamen Nenner finden, also Gemeinsame Tools, gemeinsame Prozesse, gemeinsame Art und Weise, den Fortschritt zu reporten, zu visualisieren. Selbst so banale Dinge wie Urlaub, Teilnahme, Urlaub von Projektteilnehmern zu planen, Meetings zu organisieren, welche Videokonferenzplattform wird genutzt, welches Internet-Wiki oder Ticketsystem wird genutzt. Das sind ja alle so ganz kleine Themen, die am Ende ja auch extrem viel Alignment-Aufwände bedeuten.

Sprich, wenn ich natürlich alles innerhalb einer einzigen Unternehmung habe, wird, wie gesagt, dieser Organisations- und Alignment-Aufwand geringer. Auf der anderen Seite koche ich natürlich auch ein Stück weit in meiner eigenen Suppe. Das heißt, ich habe eben weniger Impulse, weniger neue Ideen, ich habe weniger Lernkurve. Ja, weil jeder neue Partner, jeder neue Dienstleister, jeder neue Berater natürlich ein Stück weit auch Erfahrungen reinbringt, ja, vielleicht neue Tools, neue Perspektiven, neue Art und Weise, Dinge anzugehen. Also das muss man so ein bisschen balancen. Ich glaube, am Ende ist immer ein bisschen die Frage, was ist das übergeordnete Ziel des Programms? Ist das Ziel des Programms, einfach irgendwas zu liefern, also und idealerweise vielleicht in maximaler Geschwindigkeit oder in einem sehr limitierten Budget? Da wird man immer ein Setup wählen, was einfach extrem wenig Overhead erzeugt oder es wird dann eben optimal internalisiert sein, ja. ist das Ziel des Programms, zu lernen, Kompetenz aufzubauen. Also ganz häufig sieht man ja gerade jetzt in der Arbeit mit großen Konzernunternehmen, dass die alle versuchen, ihre Digitalkompetenz aufzubauen.

Und das tun sie dann einfach natürlich gestreckt über die Zeit, das heißt vielleicht über die nächsten zwei, drei Jahre, eben gemeinsam mit Partnern, bis sie da einfach auch die Quantität an Leuten und dann natürlich auch die Qualität haben. Also dann ist das Ziel des Programms nicht, nur eine App zu bauen oder nicht nur eine Commerce-Plattform zu bauen, nicht nur ein großes Content-Portal zu bauen, sondern natürlich auch Kompetenz aufzubauen, eine Organisationsstruktur zu schaffen, maximal viel Wissen aufzubauen, dann wird man wahrscheinlich ein Setup wählen, was das ein bisschen besser ausbalanciert, wo man sagt, okay, ich möchte Input haben, ich möchte Partner dabei haben, ich möchte lernen, ja, und ich verstehe auch, dass diese Lernkurve und diese Art, das Programm eben zu steuern, auch ein Stück weit auch Zeit und Geschwindigkeit kostet, ja, aber einfach liegt in der Natur der Sache und natürlich auch mehr Kosten oder Overhead-Kosten verursacht, aber das ist es mir wert, weil das quasi mehr als sich auszahlt über eben den Lernfortschritt der Organisation da vorne raus.

Joel Kaczmarek: Ich wollte dich gerade fragen, wenn du sagst, möglichst alles internalisieren, was man internalisieren kann, was ist denn die KPI, die du optimierst? Ist das quasi Geschwindigkeit? Ist das Budget? Ist das irgendwie Koordinationsaufwand? Weil an und für sich, es kann ja auch manchmal, genau wie du sagst, den externen Know-how-Zufluss geben. Manchmal ist es doch schneller, wenn man Sachen parallel extern bauen lässt, während intern ein Team was anderes macht. Auf was optimierst du, wenn du intern und extern in großen Projekten abmischst?

Boris Lokschin: Auch hier, wir haben das in ein, zwei anderen Folgen, glaube ich, schon mal besprochen. Ich glaube, das Allerwichtigste ist, dass hier wirklich auch Top-Management oder Management-Alignment da ist, bis hin zu den Eigentümern. Es hilft nichts, wenn das Projekt irgendwie ein KPI hat und übergeordnet da anders drauf geschaut wird, ne? Nochmal bei dem Beispiel zu bleiben von eben, wenn ich einfach das Ziel habe als Organisation, eine digitale Kompetenz aufzubauen, ne? Machen wir es mal ein bisschen konkreter. Ich möchte eine Digital-Unit aufbauen. Ich habe mir vorgenommen, in den nächsten drei Jahren möchte ich irgendwie 100 Leute aufbauen an einem bestimmten Standort. Bunt gemixt, möchte sozusagen technische Fähigkeiten haben, möchte planerische Fähigkeiten haben, möchte irgendwie BI-Marketing-Fähigkeiten haben. Und ich weiß ganz genau, das wird eben zwei bis drei Jahre dauern, bis ich da eine Unit habe, die zumindest die Schlagkraft hat, im Kern meine digitalen Prozesse zu bauen, sich gerne verlängert und irgendwie auch nochmal anreichert, extern, aber im Kern self-sufficient zu sein. Dann Und das ist ein Ziel, was allen klar ist. Der Erfolg wird quasi jetzt mal nach vorne gespult, dann daran gemessen, A, habe ich diese Kompetenz wirklich aufgebaut? Habe ich das hinbekommen? Habe ich da die richtigen Leute in der richtigen Zahl mit den richtigen Skills? Und B, was ist sozusagen das Trainingsmaterial on the way? Selten wird man ja eine Möglichkeit bekommen, einfach drei Jahre eine Unit zu bauen, ohne irgendwelche Deliverables. Das heißt, in der Realität wird es dann ganz häufig so sein, dass dann eben vorgegeben wird, dass man dann auf dem 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. Optimiert unser Order-Fulfillment-System im Hintergrund. Lasst uns eine Anbindung zu diesem Zahlungsdienstleister bauen. Also es wird ja diverse Projekte und Teilprojekte geben, an denen man sich quasi beweisen kann, üben kann. auch mal so tangible sozusagen Results liefern kann. Aber das wird dann der KPI sein, ja. Wenn der KPI anders gesetzt ist, wenn der KPI ist, wir wollen so schnell es geht eine Commerce-Plattform gebaut haben in den nächsten zwölf Monaten oder wir möchten so schnell es geht unser Internet irgendwie umgestaltet haben oder wir brauchen so schnell es geht eine Kunden- Und das ist der KPI, die Bereitstellung von diesem konkreten Teilprojekt. Oder wir haben jetzt 10 Millionen Euro budgetiert und die wollen wir jetzt ausgeben für XYZ. Dann wird man eben anders rangehen. Dann würde ich jetzt wahrscheinlich nicht anfangen, ein Setup zu wählen, was irgendwie 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 committen. 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 genannten Unternehmer, großen Dienstleister sucht, der dann eben mir end-to-end diesen Service oder das Produkt hinstellt.

Joel Kaczmarek: Gut, verstanden. Macht alles Sinn. Gibt es 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? Also würdest du bei kleineren oder vielleicht etwas mitteldimensionierten Projekten eine andere Externalisierung anstreben, als du es bei einem großen Projekt tun würdest?

Boris Lokschin: Umso größer ein Projekt ist, umso geringer die Wahrscheinlichkeit, dass man eben die Skills komplett selber hat. Bei einem kleinen Projekt, also machen wir ein Beispiel, wenn ich eben wirklich ein Projekt, so eine typische Projektteamgröße, wenn ja vielleicht irgendwas um die 10, 12 Leute, das ist etwas, was man durchaus entweder selber hinbekommt oder eben mit einem einzigen Partner geschenkt bekommt. So, plane ich jetzt einen globalen Rollout von irgendeiner riesen Plattform, ja, in sieben Ländern mit ganz viel Frontend, Backend-Abhängigkeiten, mit ganz viel Prozessthemen, die noch irgendwie in der Organisation umgestellt oder nur aufgebaut werden müssen, ist die Wahrscheinlichkeit, dass das eben ein Partner komplett covern kann, ist da natürlich auch geringer, ja, Oder es muss eben ein sehr großer Partner, also die Größe von so globalen sogenannten Systemintegratoren, die dann einfach 10.000, 100.000 teilweise von Mitarbeitern haben, die dann fairerweise, das ist so ein bisschen leider das Problem, die jetzt auf dem Papier diese Zahl der Leute haben, aber am Ende sind die Leute halt trotzdem geschnitten, auch wieder in kleine Delivery-Units, ja. Auch meistens regional. Das heißt also, die Wahrscheinlichkeit, dass das eben notwendiger wird und mit zunehmender Größe des Programms steigt. Und wie gesagt, Systemintegratoren können mir dazu auf dem Papier diese End-to-End-Delivery-Fähigkeit geben. Hat viele Vorteile, denn die sind meistens in der Lage, mir zumindest vertraglich quasi alles abzunehmen.

Das heißt, ich habe eine Vertragspartei, ich verhandle einmal irgendwie SLRs, ich verhandle einmal Lieferprozesse, ich verhandle einmal Timelines und Budgets und der Partner muss dann eben aus seinen meistens regional verteilten Delivery Units so ein Programm oder einzelne Projektbestandteile des Programms eben mir hinstellen. Wie gesagt, macht es meistens nicht einfacher, denn es ist dann eben tatsächlich nicht so oder in den seltensten Fällen so, dass dann auf einmal 100 Leute irgendwie aus Hamburg dann auf meiner Initiative arbeiten, sondern ich habe dann quasi einfach nur den Koordinations- und den juristischen Aufwand eben nicht mehr verteilt auf zehn Köpfe, aber unten drunter in der Delivery ist es sozusagen das SI-Problem, das eben wieder zusammenzubauen und zusammenzustellen. Gut.

Joel Kaczmarek: 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 Personengremium, was am besten von oben bis unten alles im Griff hat. Aber es gibt ja auch oft genug Situationen, wo man vielleicht eher Fachexperten hat, wo man eher möchte, dass die Teilbereiche davon nehmen. Wie ist das bei großen Projekten? Was ist eigentlich realistisch umsetzbar in Sachen Accountability und was empfiehlt sich vielleicht?

Boris Lokschin: Naja, also auch hier erst mal angefangen mit den Extrempositionen. Was ist das Ideale? Jeder Kunde möchte natürlich idealerweise End-Vendor Accountability haben. Das heißt, du möchtest eigentlich ruhig schlafen, möchtest komplett sicher sein, dass es irgendwie diesen einen Joel gibt, den ich an die Hörner fassen kann, wenn das irgendwie nicht funktioniert, der zu jeder Zeit den vollen Überblick hat über alle Bestandteile, der zu jeder Zeit alle Partner, Dienstleister und Involvierte auch entsprechend pushen kann. und managen kann und nach vorne treiben kann, ja, der einen Wundersack hat auch an Ressourcen, um das auszubalancieren, wenn in dem einen Teilprojekt Dinge nicht vorangehen, dann kann er Leute umschichten von links nach rechts und der am Ende sozusagen für alles gerade steht, ja, wenn das nicht funktioniert, den du bestrafen kannst, wenn das nicht läuft und Co., Das gibt es, das kann man so machen. Hat natürlich sehr, sehr viele Nachteile. Klar, die Vorteile sind erstmal klar. Die Nachteile sind natürlich A, diejenigen, die in der Lage sind oder auch bereit sind, auch dieses Maß an Verantwortung zu übernehmen und auch zu tragen, lassen sich bezahlen. Das ist, glaube ich, relativ klar. Das ist am Ende eine Versicherung und auch ein nicht zu unterschätzender, auch personeller Koordinations- und Steuerungsaufwand. Also das heißt, der Partner wird das immer einpreisen. Der Partner wird immer Also A, das Risiko einpreisen, B natürlich auch die Steuerungsressourcen, die dafür notwendig sind, einpreisen. Und was aber vielleicht noch am allerschwersten wiegt bei sowas ist, dass Accountability und Empowerment immer Hand in Hand gehen. Das glaube ich, hatte ich in einem anderen Podcast auch schon mal gesagt. Das heißt, jemand, der Accountability übernimmt… wird immer das Empowerment fordern. Was heißt das? Bedeutet nichts anderes, als dass er sagen wird, okay, wenn ich verantwortlich sein soll dafür, dass das Programm in Time, in Budget, in Quality, in Scope geliefert wird, dann brauche ich auch vollen Durchgriff. Das heißt, ich muss eben in der Lage sein, komplett Dinge so auch bauen zu können, wie ich das für richtig halte. Ich muss vollen Durchgriff haben über alle Partner, Dienstleister. Ich muss weisungsbefugt sein. Ich muss im Zweifel auch intern Mitarbeitenden gegenüber weisungsbefugt sein. Das heißt also, ich muss in der Lage sein, auch deine eigenen Leute zu steuern. Denn wie soll ich denn sonst die Verantwortung tragen, wenn jeder arbeitet, wie er will, wann er will, tut, was er will und ich immer wieder irgendwie in Diskussionen reinlaufe, weil der Partner nicht gerade ansteuere, mir aber sagt, mit ihm war eine ganz andere Timeline verabredet oder da ist schon kein Budget mehr auf dem Thema, an dem er arbeitet oder irgendwie wurde in ganz anderer Art und Weise besprochen, die Dinge zu erledigen. Und das kann eine nicht zu unterschätzende Downside sein, gerade eben im Hinblick auf das, was wir vorher besprochen haben. Wenn mein Anspruch ist, Digital-Kompetenz aufzubauen nach vorne raus, also wirklich auch Ownership zu haben, dann tue ich ja damit erstmal nichts anderes, als genau das abzugeben. Das heißt, ich baue eben überhaupt keine Ownership auf, ich handele, ich trade sozusagen dieses, ich kann ruhig schlafen und es gibt jemanden, der mich an die Hörner fassen kann, gegen Ownership. Ein komplett mehr oder weniger outgesourcetes Blackbox-Modell, bei dem ich mich zurücklehne, mehr oder weniger entspannt und darauf warte, dass irgendeine Blackbox geliefert wird. Aber das ist natürlich quasi auch ein Stück weit das Antimodell von modernen, zumindest Digitalprojekten. Und nicht nur das Anti-Modell, sondern es führt auch, das hat auch eine ganz gefährliche Nebenkomponente, nämlich sogenannte Log-In-Effekte. Das heißt, derjenige, dem du, das ist immer so ein bisschen die andere Seite der Medaille, derjenige, dem ich diese Art von Power gebe, der Der hat sie dann auch. Und dann habe ich eben ein Stück weit auch mich selbst in so einen goldenen Käfig vielleicht gesetzt und komme dann eben nicht mehr raus. Da ist sehr, sehr viel Projekt-Know-how, sehr viel Kontext, sehr viel Detailwissen, was eben bei einem Partner da liegt. Das muss nicht schlecht sein. Es gibt ja auch sehr gute, sehr fruchtvolle, sehr langjährige Partnerschaften. Also ich will auf gar keinen Fall sozusagen dieses Modell jetzt irgendwie schlecht machen. Aber das ist einfach ein Trade-off, man muss sich dessen bewusst sein und sich dann entweder sehr aktiv dafür entscheiden, aber zu hoffen, dass man eben 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. Das wird es in der Realität nicht geben. Also das ist etwas, auf was man sehr, sehr stark schauen muss und dann sich entscheiden muss, macht man das Modell oder eben das Gegenmodell davon.

Joel Kaczmarek: Aber was du gerade beschrieben hast mit Empowerment und Accountability, lässt sich das in großen Projekten denn eigentlich wirklich durchgreifend realisieren? Weil wenn die so groß sind, wie wir sie jetzt eigentlich mal, also wir sind ja vage geblieben, was heißt für uns groß? Aber wenn da viele Abteilungen mit dran beteiligt sind, es unterschiedliche Deadlines gibt, Projekttöpfe und so weiter und so fort, dann wird das doch kaum realisierbar sein in der Regel, oder?

Boris Lokschin: Ja, das ist auch der Grund, warum wir, glaube ich, alle jeden Tag in der Presse lesen, warum solche großen Projekte irgendwie total aus dem Ruder laufen, budgetmäßig und timeline-technisch oder eben nicht aus dem Ruder laufen, budgetmäßig, aber dann irgendein Quatsch geliefert wird. Es gibt ja auch viele öffentlichkeitswirksame IT-Projekte der letzten paar Monate aus unserem Umfeld. Also ja, es ist schwierig, wobei Hier muss ich sozusagen die Lanze brechen, weil für die ganzen IT-Kollegen, es ist grundsätzlich schwierig. Das hat jetzt nichts damit zu tun, ob jetzt ein Partner da irgendwie gut ist oder nicht. Das ist einfach grundsätzlich ein superschweres Thema, wie alles im Leben. Umso mehr Köche da mitkochen, umso mehr Leute da rumlaufen, umso heterogener die Landschaft, Technologie, mehr Schnittstellen. Also es ist schon Brett, ja. Aber genau deswegen versucht man das eben auch anders zu schneiden und im Zweifel irgendwie eine Balance zu finden, die zum Beispiel so aussehen kann, dass man sagt, okay, die zentrale Steuerungs- und Koordinationskompetenz, die möchte ich gar nicht zukaufen. Das heißt also, das Risiko, das nehme ich als Unternehmen selber. Also mir ist klar, dass ich eben nicht mehr diesen einen Partner habe, der für alles gerade, also diesen Generalbauunternehmen habe ich nicht, sondern ich bin das jetzt selber. 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 on the way getroffen worden sind. Ich nehme damit natürlich auch die Verantwortung auf, mich diese einzelnen Gewerke zu koordinieren. Das heißt, ich habe dann eben die drei, vier Partner, die dort unterwegs sind. Ich muss dafür Sorge tragen, dass die Arbeitsweisen, Methoden, Inhalte, Scope, Timelines, Budgets abgestimmt sind. Das ist eine wichtige Kompetenz. Fairerweise aber eine, die ich sowieso brauche. 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, brauche ich so oder so, ja, denn die Annahme nach vorne raus, dass Projekte weniger komplex werden oder ich weniger Technologie haben werde, weniger technologische Frameworks, weniger technologische Technologieexperten im Unternehmen, die ist ja, glaube ich, nicht richtig, ja, das heißt, das ist ja sozusagen eine natürliche Entwicklung, dann fange ich lieber jetzt damit an und nutze auch die Chance, denn was auch klar ist, ist, in ein bestehendes Projekt oder Programm einzugreifen und also inhaltlich einzutauchen und dann Know-how zu übernehmen, das ist fast unmöglich. 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, Re-Platforming, Neuaufbau von einem Projekt und einem Programm, wo eben genau die Dinge neu entstehen. Ja, 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 Org-Chart im Lead als Unternehmen, trotzdem habe ich aber Partner, vielleicht eher beratender Natur, die by my side sind, die mir helfen, die mir Guidance geben, die mir auch helfen. die sozusagen Frameworks geben, die mir zeigen, wie ich Ressourcen zu planen habe, wie eine Timeline zu organisieren ist, wie ich Gantt-Diagramme zeichne, wie ich Abhängigkeiten und kritische Pfade bedenke, welche coolen Tools es gibt. Das kann man ja alles machen, ohne aber zu sagen, ich bin aber dafür nicht verantwortlich, sondern das macht jetzt der Joel, sondern ich kann mir komplett selber die Accountability nehmen, mich aber sozusagen links und rechts schon auch mit Partnern umgeben, die dann das Know-how transferieren. Das ist auch gut, weil ich dann natürlich als Auftraggeber, als Projektinitiator, Programminitiator immer einen besseren Durchgriff habe. Ja, es ist ja eine Sache, als wenn du drei Partner managst, die alle für dich arbeiten oder einen Vierten diesen Aufwand rausgibst, der drei Partner zu managen hat. Da hast du dann immer Dinge, wo du nicht 100% reingucken kannst. Von irgendwie laxender Steuerung bis hin zu fetter Wirtschaft, was nicht alles gibt. Also es ist immer leichter, selber die Hand drüber zu halten und es ist auch immer effizienter.

Joel Kaczmarek: Gut, abschließendes Thema, der Classic. Was sind so typische Sollbruchstellen? Woran scheitern große Projekte klassischerweise? Also Accountability ist wahrscheinlich ein großes Thema, was wir schon hatten. Die Abmischung intern-extern vielleicht auch. Und Zuschnitt, gibt es sonst irgendwie typische Classics, wo du sagst, dass es sich eigentlich immer wieder in der Praxis daran scheitert?

Boris Lokschin: Ja, also was super, was mittlerweile sehr witzig ist, ist, dass viele Unternehmen gelernt haben oder beigebracht bekommen haben, wie die einzelnen Projekt- oder Teilprojekt-Bausteine mehr oder weniger agil und effizient und sozusagen nach modernen Best Practices zu führen sind. Also wenn du sozusagen dann reinzoomst in die einzelnen Bausteine und sagst, okay, wie arbeitet das Team, was die App baut oder wie arbeitet das Team, was jetzt hier diesen Kundenprozess baut, dann sieht das erstmal alles gar nicht so schlecht aus. Das Hauptproblem entsteht eigentlich immer mittlerweile im Querschnitt, in den Querschnittsfunktionen. Das heißt, am Ende möchte ich ja nicht die Summe von zehn top-optimierten Silos haben, sondern ich möchte ja in der Lage sein, end-to-end eine Hose in den Warenkorb zu legen und die zu kaufen oder eine Banane in den Warenkorb zu legen und die zu kaufen oder ein Versicherungsprodukt zu konfigurieren und das dann zu bestellen. Das ist ja in der kundenzentrischen Welt eigentlich die Aufgabe des Programms oder des Projekts. Und darunter gibt es natürlich ganz viele Systeme und Leute und Abteilungen, Was eben momentan ganz klar ist, ist eben überall da, wo du eigentlich so einen horizontalen Schnitt durch die einzelnen Silos, vertikalen Teams, Projektteams, you name it, machst. Das sind dann so Themen wie zum Beispiel Testing. Also wie organisiere ich eine übergreifende Teststrategie zwischen diesen einzelnen Silos, sodass ich wirklich auch entwickle. End-to-End und auch Integrationstests habe und wirklich sehen kann, wie landet eben der Schuh, wie kommen Produktdaten in das System, wie sucht ein Kunde, wie legt er das in den Warenkorb, wie kauft er es, wie landet es beim Payment, wie landet es beim Fulfillment, wie landet es beim Customer Service. Einfach einmal diesen horizontalen Schnitt durch eben diese 5, 6, 7 Teilprojekte. Themen wie zum Beispiel Business-Readiness, ganz klar. Ich habe ja ganz viele Themen, die jetzt nicht so Feature sind, sondern ich muss einfach Daten anlegen, ich muss mal irgendwie E-Mail-Templates befüllen, ich muss mal so einen Payment-Provider konfigurieren, ich muss vielleicht irgendwie Content-Seiten oder Produkt-Information-Seiten pflegen. Also klassisch Business-Readiness-Themen, wo nicht die Entwickler, die Entwickler haben alles schön hingekodet und Feature funktioniert mit Dummy-Daten wunderbar und Lorem Ipsum steht auch überall drin und Produkt XYZ für 99,999 Euro, liegt auch im Warenkorb, aber irgendwie ist das noch nicht so, dass du sagst, jetzt kann der End-User mit drauf. Also Testing, Business Readiness, also Daten, weil jetzt sozusagen das Dritte, was da rauskommt, also wirklich Stabilität. Stammdaten, Content-Daten, Produktstammdaten, ja, Kundendaten, Migration von irgendwie aus Altsystemen, ja, alte Passwörter, alte User-Daten, das sind so alles Sachen, die liegen quasi in niemandes. Zuständigkeit in so einem stark geschnittenen Programm, weil jeder baut seine Funktionalität, jeder stellt seine App hin, aber am Ende funktioniert es dann eben trotzdem. Dokumentation, sodass 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, dass sich jemand Neues damit zurechtfindet, der das irgendwie übernehmen kann. Betrieb, also Infrastruktur, Cloud, Skalierung, Deployment.

Wer kümmert sich darum? Also das sind so Dinge, die in der Praxis eben entsprechend Aufwand brauchen. und auch hier zurück zu dem, was wir vorhin besprochen haben. Umso feiner geschnitten die Teams, also ich muss immer diese Balance finden zwischen Ich kann fein schneiden, dann habe ich autarke, selbstständige, eigenverantwortliche Teams, erhöhe damit aber immer diesen Querschnittsaufwand. Und ich muss ein Programm immer so ausbalancieren, dass sich die Dinge irgendwie in der Waage halten und eben nicht dazu führen, dass ich jetzt 37 kleine Teams unten drunter habe, aber der Koordinations- und Overhead-Aufwand, budgetär und ressourcenmäßig, diese ganzen Vorteile wieder sofort aufgefressen hat. Ich möchte aber auch nicht einen riesen Querschnittslayer auf ein Team aus zwei Projekten in einem kleinen Programm legen. Möchte ich auch nicht. Das heißt, ich muss das irgendwie entsprechend smart und deswegen wieder zurück zum Initialpunkt, smart schneiden initial, sauber ausbalancieren und mir immer wieder die Frage stellen, wofür will ich verantwortlich sein? und dann eben diesen Aufwand zwischen den einzelnen Projekten und dem Programm so austarieren, dass er in Summe immer noch effizient ist und eben nicht mehr Arbeit verursacht, als er Ertrag bringt.

Joel Kaczmarek: Gut, also Querschnittslogik plus irgendwie sinnhaftes Austarieren und dann so eine gewisse, ich sage mal, Hygiene, Prozesshygiene, über die du ja gerade gesprochen hast. Wie kriegst du es hin, dass wenn Themen anfallen, die jetzt auf niemandem Tisch liegen, also was du gerade beschrieben hast, zum Beispiel Testing oder Dokumentation, dass da sich jemand verantwortlich fühlt? Ist das dann wieder so eine Frage von Accountability nach oben hin oder ist es eine Kulturfrage? Hast du da irgendwie für dich was gefunden?

Boris Lokschin: Naja, also es ist auf jeden Fall eine Frage von, also du musst ganz simpel haben, du musst erstmal jemanden verantwortlich machen dafür. A sind mittlerweile oder heutzutage die Silos natürlich selber alle für sich selbst verantwortlich, inkrementell sich selbst zu testen, sich selbst zu optimieren. Ja, aber dieser übergeordnete Aufwand, ja, den du eben immer hast, also irgendeinen Prozessverantwortlichen zu haben, ja, das macht man meistens eben auf Ebene des sogenannten Programmmanagements, dass du da einmal In zwei Wochen, einmal im Monat Leute hast, die dann, so ein bisschen wie in so einer Demokratie, die dann sozusagen die Repräsentanten der einzelnen Projekte oder der Teilprojekte sind, die dann zusammenkommen und die dann entsprechend aligned werden. Also wie sieht die Timeline aus, wie sieht die Ressource-Verteilung aus? Das ist eben klassische Aufgabe eines Programmmanagers. eben nicht die einzelnen Silos zu optimieren, sondern zu sagen, Joel hat in seinem Team zehn Leute, Boris hat acht Leute, Joel kommt ein bisschen besser voran, Boris ein bisschen schlechter, jetzt nehmen wir vielleicht mal zwei Leute von Joel zu Boris ins Team, gucken, dass wir das mal ein bisschen austarieren. Das wird ja keiner von uns beiden individuell entscheiden können, weder du willst Ressourcen abgeben, noch ich kann Ressourcen von dir klauen. Das heißt, das muss eben ein Programmmanager beschließen oder auch abhängig sein, zu sagen, hör zu, Boris kommt vielleicht nicht so schnell voran bei dem Teil. Das ist aber für den nächsten Sprint bei Joel wichtig, weil sonst kann er nicht starten. Jetzt lass uns mal entscheiden, dass wir die Aufgaben entsprechend tauschen oder wir merken, dass wir hier gerade ganz viel schwarze oder blind Spots haben, weil eben die beide mit zwei verschiedenen Tools arbeiten und eben nicht die Übersicht haben über den Fortschritt. Lass uns vielleicht auf ein Tool wechseln. Das sind so Dinge, die man ins Programmmanagement legt Und dazu gehören dann eben auch solche Dinge wie übergeordnete Teststrategie, Business Readiness Checklisten, Infrastruktur, Deployment Tasks und Co.

Joel Kaczmarek: Superb. Also, ich glaube, es war ein guter, spannender Ritt. Ich hoffe, dass jetzt viel, viel mehr große Projekte gut laufen, nachdem man dir zugehört hat. Hast du ein bisschen einen aktuellen Aufhänger gehabt? Also hast du es jetzt öfters mal gehabt, dass du gesehen hast, okay, große Projekte bei Kunden von euch gehen gegen die Wand? Also ist das nach wie vor was, was einfach zur Tagespraxis gehört?

Boris Lokschin: Also gegen die Wand nicht, aber was ich natürlich schon sehe, ist also logischerweise mit steigender Größe von uns selbst und jetzt natürlich auch mit zunehmender Internationalisierung. Wir machen es ja sehr, sehr, sehr, sehr viel in den USA, UK, Nordics und irgendwie anderen Ländern. Merkt man natürlich schon, dass auch die Projekte oder die Programme dann eben größer, nationaler werden, mehr Business Units, größerer Scope, größere Dimensionen. Und die Unternehmen selber natürlich auch noch größer werden. Und da merkt man eben schon, was da so das gemeinsame Pattern momentan ist für Success oder Failure. Und das finde ich eben super spannend zu sehen, dass viele in den einzelnen Teilprojektbereichen tatsächlich gar nicht so super schlecht organisiert sind. Also das kann man schon reinschauen und hier und da inkrementell verbessern. Aber im Wesentlichen sind die Projekte okay, wo es eben tatsächlich total kränkelt und hapert oder wo einfach viel Risk drin liegt, ist eben auf der Programmmanagement-Seite. und ja, einfach umso größer und umso heterogener, umso verteilter, umso mehr Partner, Dienstleister, umso weniger man selber Kompetenz hat, umso größer die Risk-Flex, das heißt nicht, dass es nicht funktioniert, aber es ist auf jeden Fall dann so ein Thema, weil fairerweise aus Unternehmenssicht ist es am meisten so, dass natürlich die Unternehmen wollen einfach dieses fertige Resultat, ja, Aber dieser Link zwischen ich möchte das fertige Ergebnis und ich habe jetzt auf einzelnen Ebenen eigentlich alles gut hingestellt. Also diese Klammer, die sozusagen fehlt, die ist nicht allen ersichtlich. Und ich glaube, da ist viel zu tun noch. Gut.

Joel Kaczmarek: Liebe Hörerinnen und Hörer, wir freuen uns natürlich auch immer über eure Anregungen. Wenn ihr noch was beizusteuern habt, schreibt uns doch gerne zum Beispiel auf LinkedIn. Also Boris ist dort als Boris Lok schon unterwegs, freut sich glaube ich über Follower, Vernetzung und Co. Und ich auch unter Joel Kaczmarek. Lieber Boris, vielen, vielen Dank. Und ja, ich bin mal gespannt, was ich noch in den nächsten, also bestimmt machen wir mal ein Update. Ich könnte mir vorstellen, dass das irgendwann nochmal aufkommt, das Thema neue Learnings zum Thema Projekte managen, die über das Größere generiert sind. In diesem Sinne, danke dir und gutes Gelingen.

Boris Lokschin: Dankeschön, ciao.