Projekttetris: Erfolgreich mehrere Projekte managen

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate-or-Die-Podcast von Digitalkompakt. Mein Name ist Joel Kaczmarek und heute geht es um ein Thema, was, glaube ich, gefühlt jeden beschäftigt, der sich mit Thema IT auseinandersetzt, aber eigentlich generell mit Unternehmertum, nämlich Projekt Tetris. Ihr werdet, wenn ihr euch darin wiederfindet, zu viele Projekte auf einmal machen zu wollen, viel, viel Tipps kriegen in die Richtung, sollte ich eigentlich parallel oder sequenziell arbeiten? Was für Beispiele gibt es eigentlich, gerade so im IT, aber auch im Commerce-Bereich, wo der gute Boris, zu ihm gleich mehr herkommt, und natürlich auch Best Practices. Das heißt, hinterher hat man eigentlich so einen kleinen Marschplan. Wie sollte ich mit Projekten umgehen, wenn ich zu viel auf einmal will? Die Krankheit, glaube ich, jedes Unternehmers immer alles auf einmal und immer möglichst gestern. So, lieber Boris, schön, dass du da bist. Herzlich willkommen.

Boris Lokschin: Ja, vielen Dank. Frohes neues Jahr an alle Zuhörer hier.

Joel Kaczmarek: Ebenso, neues Jahr, neue Vorstellung. Erzähl doch mal nochmal zwei, drei Sätze zu dir. Vielleicht auch mal einen Satz, was dich gerade umtreibt und dann starten wir hier munter rein.

Boris Lokschin: Ich bin Boris, bin einer der Co-Gründer und CEO von Spryker Systems. Wir sind ein Commerce-Technologieanbieter aus Berlin, bauen eine moderne Commerce-Lösung für den B2B, B2C-Markt, für Händler, Marken, Hersteller. Wir haben, glaube ich, da ganz spannende Dinge vor, haben jetzt das letzte Jahr sehr erfolgreich verlassen. Da sind knapp 250 Leute mittlerweile in Berlin, Hamburg primär, auch an sieben Standorten im Ausland, expandieren jetzt in Benelux, UK, Nordics, arbeiten mit, glaube ich, ganz vielen spannenden Use Cases zusammen und die helfen dann immer so ein bisschen auch hier die Thementüte zu befüllen für diesen Podcast.

Joel Kaczmarek: Meine Güte, Benelux, da müssen wir auch mal eine Folge machen über Internationalisierung von IT. Also das erklärt schon ein bisschen, wir werden sicherlich einige Beispiele aus dem Commerce-Bereich haben, die sind ja auch immer so schön anschaulich. Und ich bin großer Boris-Fan, sage ich ja immer. Also hast du mal On-Air-Kompliment von mir hier. Boris macht das immer so schön strukturiert und ich kann euch schon sagen, heute zu Projekt Tetris wird auch cool. Aber straight reingestartet, als wir ankamen, das Thema machen wir heute eigentlich, dann hast du gesagt, ja, was Aktuelles, was mich beschäftigt. Ist es so, dass du oft darauf triffst, dass Leute viele Projekte gleichzeitig machen?

Boris Lokschin: Genau, also das passiert, glaube ich, sehr, sehr häufig, ich würde sagen, acht von zehn Cases, die jetzt an uns herangetragen werden. Da ist es, glaube ich, immer so, dass die Leute sich mit zu vielen Dingen gleichzeitig beschäftigen, sei es in Form der Ausschreibung, die dann auf dem Tisch landet oder auch einfach in Form der Vorgespräche, die wir dann haben, merkt man einfach, dass es eben nicht nur um das Commerce-Projekt geht, sondern dass dann eine ganze Systemlandschaft gezeichnet wird, was erstmal per se nicht verkehrt ist. Es gibt eben viel Innovations- und Transformations- und Migrationsdruck momentan. Vor allem B2B-Segmente, wo immer noch viele veraltete Systeme da sind. Die Frage ist eben nur, wie gehe ich das an? Ist das schlau, alles auf einmal vorzunehmen? Mache ich das eher nacheinander? Was sind so die Pros und die Cons? Darüber, glaube ich, können wir heute ein bisschen diskutieren.

Joel Kaczmarek: Gut, dann hat man ja im Prinzip so diese beiden Optionen. Parallelfahren versus sequenziell. Jetzt war so meine Hypothese, speziell Unternehmer wollen immer alles parallel machen. Und wie gesagt, eigentlich gestern. Was ist denn so deine Beobachtung? Also was spricht denn wofür?

Boris Lokschin: Klar, wir können das immer so ein bisschen auseinandernehmen, die Makroperspektive und dann ein bisschen tiefer eintauchen in die Punkte. Also ich glaube, wenn man erstmal drauf schaut und sich überlegt, okay, ich habe eine gewisse Zahl an Projekten, machen wir mal ein Beispiel, ich habe irgendwie ein Commerce-Projekt und ich möchte gleichzeitig vielleicht nochmal mein PIM erneuern, weil ich brauche ja schöne Stammdaten, ich möchte die vielleicht über mehrere Kanäle ausspielen. Was ist ein PIM?

Joel Kaczmarek: Sag doch mal, ich weiß das ja.

Boris Lokschin: Genau, das ist ein Produktinformationsmanagement-System. Häufig, wenn ich über viele Kanäle verkaufe, online, offline, vielleicht irgendwelche Print-Kanäle noch, dann habe ich Daten zu meinen Produkten an einem zentralen Ort und dann spiele ich die in die verschiedenen Kanäle aus. Das heißt, ich brauche natürlich Produktdaten, ich brauche natürlich Bilder. Das heißt, ich habe noch ein Digital Asset Management-System, wo meine Bilder und Grafiken und Banner und alles schön strukturiert in verschiedenen Größen und Auflösungen und für die verschiedenen Devices voraufbereitet quasi abgelegt wird. So, und dann überlege ich mir, okay, ich möchte eigentlich ein Commerce-Projekt machen, ein PIM und dann eben ein DAM einführen oder vielleicht eine Website relaunern. Was gibt es da für Pros und Cons? Also Timelines, glaube ich, ist das Erste. Ich glaube, man könnte natürlich die Behauptung aufstellen, dass wenn ich parallel Projekte abwickle, jetzt mal über das Thema, kann ich das überhaupt und was brauche ich dafür, können wir nachher nochmal sprechen, dann bin ich schneller fertig. Im idealen Fall ein gut gemanagtes, paralleles Projekt dazu führt, dass ich einfach schneller fertig bin mit der ganzen Baustelle und dann kann der Zug einfach wieder sauber rollen und ich kann mich eben auf Themen nach vorne raus konzentrieren. Ich habe so einen Peak-Stretch für meine Organisation, das heißt, ich habe immer eine gewisse Zeit, super viel Belastung. Meine ganzen Leute müssen vielleichtmit mehreren Systemen parallel arbeiten. Trainings als Zusatzaufgabe pro Tag. Ich habe vielleicht noch mal hier und daso ein paar Hiccups mit meinen Datenund Fehler und Co. Aber das ist eben ein Peak. Und irgendwann ist dieses Peak auch wegund ich habe irgendwie alles abgearbeitet. Und dann bin ich eben wieder im Tagesgeschehen Ich habe aber ein bisschen die Schwierigkeit auf der anderen Seite, dass ich es schwerer habe beim Finden der Fehler, auch bei der Ursachenforschung. Das heißt, wenn ich irgendwie zwei, drei, vier Dinge auf einmal ausgetauscht habe und irgendwas funktioniert nicht, dann kann ich es eben nicht klar verorten, kann nicht klar zurückführen auf ein konkretes System, sondern muss mir überlegen, sind die Daten jetzt schlecht abgelegt worden in meinem PIM? Ist die Schnittstelle schlecht? Wurden die Daten schlecht übertragen? Oder ist der Shop vielleicht fehlerhaft? Zeigt er sich falsch an? Und wie gesagt, die Anforderungen an Team und auch Ressourcen sind, glaube ich, schwerer. Auf der anderen Seite, wenn ich sequentiell mache, strecke ich natürlich die Timeline. Das heißt, ich mache Projekt A, ich mache zuerst mal PIM, sorge dafür, dass das eingeführt wird, dass die Daten sauber sind, dass ich vielleicht auch nochmal integriere mit meinem alten System. Das ist auch nochmal ein wichtiger Punkt zum Thema Kosten, auf den wir nachher zukommen. Und sobald das Projekt erfolgreich ist, nehme ich mir quasi ein neues Projekt an und sage, jetzt ist das PIM da, jetzt kann ich das integrieren mit meinem Shop. Und wenn das Shop da ist, dann mache ich irgendwie wieder das nächste. Bottomline wird wahrscheinlich sein, dass auf der Brutto-Zeitachse das Projekt länger dauert. Das heißt also, weniger Stress habe für meine Organisation. Ich habe ja nicht drei, vier, fünf, sechs Baustellen gleichzeitig, aber ich habe es eben dann auf einen längeren Zeitpunkt gestreckt. Das heißt also, meine Fähigkeit wirklich nach vorne an Themen zu arbeiten, ist halt zeitlich versetzt. Ich habe dafür aber eine leichtere Testbarkeit. Ich habe natürlich dann immer so ganz einzeln isolierte Baustellen. Wenn irgendwie Daten schlecht sind, dann ist es halt im PIM, weil der Shop ist ja immer noch der gleiche, hat sich ja nichts verändert. Und ich kann natürlich dann leichter auch meine Leute ranführen, trainieren, schulen, ausbilden und Co. Ich habe da ein bisschen weniger Belastung. Also erstmal so ein bisschen auf dem Makro-Level.

Joel Kaczmarek: Gut, jetzt hast du ja eigentlich schon mal das Thema Kosten angedeutet. Das Makrolevel war ja bei dir idealisiert. Du hast gesagt, wenn ich jetzt irgendwie parallelisiere und es gut manage, dann stellt sich die Frage, wie viele Leute managen es gut. Wahrscheinlich kommt einfach in der Praxis viel dazwischen. Ist es wahrscheinlich schneller und damit irgendwie favorisiert bei vielen? Aber was sagt denn so die Erfahrung? Also Kosten müssen ja jetzt nicht nur monetär sein, das kann ja manchmal auch irgendwie, was du gerade Peak-Stretch genannt hast, sein, also dass deine Organisation sehr am Stresslevel ist, dass du Debugging-Fehler hast, das kann irgendwie Verzögerung durch Projektfehler sein, die dich dann an anderer Stelle Geld kosten. Also hast du so einen Erfahrungswert, was mehr Kosten produziert, parallel oder sequenziell?

Boris Lokschin: Das Parallele wird vermutlich mehr Kosten produzieren. Man nennt das Programmmanagement. Das heißt, wenn ich mehrere Projekte habe, die werden in so ein Programm zusammengefasst. Das ist dann mein Digitalisierungsprogramm oder mein Customer-Facing-System-Programm, wo ich dann eben meinen PIM, meinen CMS, meinen Shop austausche. Wenn man jetzt ein paar Folgen zurückdenkt, da hatten wir ja auch ein bisschen uns unterhalten über Projektmanagement-Methoden und Do's und Don'ts. Viele haben ja tatsächlich immer noch mega Schwierigkeiten, digitale Projekte sauber zu managen, weil es einfach andere Metriken sind, andere Risikomanagement-Frameworks. Das wird natürlich nicht leichter dadurch, dass ich dann drei, vier, fünf Projekte dieser Art habe und dann auch noch parallel mit wahrscheinlich auch vielen Abhängigkeiten. Das heißt, ich muss nicht nur jedes Projekt für sich überwachen und schauen, dass das irgendwie gesund ist und on track ist und der Burndown des Budgets und der Timeline des Scopes vernünftig ist, sondern dass die eben auch aufeinander abgestimmt funktionieren. Und das ist natürlich eine Fähigkeit, die dann noch weniger Companies haben. Was wir da ganz häufig sehen, ist, dass man sich da eher verstärkt nochmal mit externen. Es gibt viele Beratungen, Management, Projektmanagement, Beratungen, die sich explizit auf sowas konzentrieren, die dann Top-Leute haben, die einfach sehr komplexe Programme geleitet haben. So ein bisschen wie in so einer Schaltzentrale von der Deutschen Bahn, wo man dann so ganz, ganz viele Gleise und viele Züge und Fahrpläne aufeinander abzustimmen hat. So ein bisschen sieht das bei denen dann auch aus. Die sitzen dann da und überlegen sich, okay, was ist auf dem kritischen Pfad? Was muss bis wann passieren? Managern auch das Budget. Vielleicht habe ich in einem Projekt ein bisschen was über, in dem anderen bin ich vielleicht ein bisschen über Budget. Das heißt, ich versuche das irgendwie gegeneinander auszugleichen. Wer muss wann anfangen mit Testen? Was passiert mit der Datenmigration? Also das ist kein leichtes Unterfangen. Von daher würde ich die These aufstellen, dass ein parallel geführtes Projekt, einfach damit es überhaupt funktionieren kann, deutlich seniorigere und erfahrene Ressourcen braucht. Entweder intern, also teure Managementzeit von Leuten intern oder eben von externen Leuten. Bei den sequentiellen Projekten ist das ein bisschen schwierig, weil man hat ja da das Risiko, was wir glaube ich auch schon mal thematisiert hatten, dass eben die Projekte endlos werden, dass unterm Strich auf einen Brutto-Zeitraum von vielleicht irgendwie zwei Jahren strecken, wenn man dann sozusagen die einzelnen Kostenpositionen mal addieren würde, dass das wahrscheinlich auch keine günstige Rechnung ist. Aber ich glaube, die meisten würden sich eher schwer tun mit dieser parallelen Geschichte, weil dort einfach in einem sehr kurzen Zeitraum einfach so ein Peak auch an Kosten entsteht würde.

Joel Kaczmarek: Jetzt juckt es einen natürlich,in den Fingern schon mal zu fragen,wem würdest du was empfehlen? Aber ich glaube, wir sollten mal als erstesvielleicht ein paar Beispieleund Best Practices durchdeklinieren. Was wären denn so typische Beispielevon Projekten, wo du beobachtest,die irgendwie werden gerne parallelisiert? Also ein Beispiel hatten wir ja jetzt schon. Gibt es so Klassiker?

Boris Lokschin: Genau. Der absolute Klassiker, vor allem im Commerce-Umfeld, ist die Kombination mit einer Neueinführung eines ERPs. Das heißt, ich habe ein Warenwirtschaftssystem und möchte dem parallel mein Commerce-System ablösen. Das ist, glaube ich, so die Mutter aller Projekte. Erstmal inhaltlich gar nicht so viel gegen zu sagen, weil tatsächlich natürlich auch die meisten ERP-Systeme relativ veraltet sind und sich auch schwer tun mit der Integration, mit sozusagen moderner Technologie. Plus auch Geschäftsmodelle sich natürlich bei den Kunden wandeln, viele Prozesse auch anders werden, mit zunehmendem Digitalisierungsgrad. Von daher ist ERP plus Shop eine ganz gern genommene Mischung. Aber um das gleich vorweg zu sagen oder vielleicht in so einer Ampelsprache, also absolut auf Rot. Also das ist die absolute Anti-Best-Practice-No-Go. Also wenn hier einer zuhört und sein Projekt dann noch nicht aufgesetzt hat, also davon würde ich ganz stark die Finger lassen. Das sind einfach zwei sehr, sehr komplexe Themenblöcke. Gerade so eine Warenwirtschaft, die hier super tief reinschneidet in alle möglichen Prozesse, quasi einen vertikalen Schnitt durch die Organisation macht, über Einkauf, Logistik, Zahlungsprozesse, Zahlungsströme, Reporting, Finanzsysteme. Also das ist, glaube ich, ganz schwer. Was wiederum schon geht oder was man machen sollte, ist, wenn man plant, sein ERP zu ersetzen, ist es total relevant, sich auch im Kontext von eben den digitalen Frontend-Systemen schon mal ein paar Dinge, so ein paar Blueprints sich an die Wand zu malen. Also konkret zum Beispiel sowas wie Abstraktion von Schnittstellen. So wenn ich schon weiß, dass nach dem Shop-Projekt ich mich auch um die Warenwirtschaftseinführung kümmere, dann macht es wahrscheinlich nicht so viel Sinn. unendlich viel Fleiß und Liebe und Mühe in den oldschooligen Schnittstellen zu meiner alten Wawi zu bauen, sondern wahrscheinlich dann eher zu abstrahieren. Das heißt, sich irgendwie saubere Interfaces zu überlegen, vielleicht eine Middleware zu verwenden oder irgendeine andere Art von Integrationsschicht, um hinterher einfach leichter das ERP unter der Haube quasi austauschen zu können. Das geht ganz gut. Und auch die Überlegung, was gehört wohin? So ein bisschen aus der alten Welt kommend sind viele Unternehmen irrationalerweise, muss man dazu sagen, dabei ihre Warenwirtschaftssysteme unnötig aufzublasen mit Funktionalität, was so ein bisschen ein Widerspruch in sich ist, weil wenn es ein Standardsystem gibt, dann ist es das ERP, bestimmt nicht das Shop und das ist auch nicht das Community-System oder das CMS. Das ist dann die Mutter aller Standardsysteme. und wie der Name schon sagt, Standardsystem lebt natürlich davon, dass ich Geschäftsprozesse habe, die standardisierbar sind, die ich auch leicht bekomme, die ich über Konfiguration bekomme, die kaufmännischen Regeln entsprechen in der Finanzbuchhaltung oder irgendwelchen Legal-Anforderungen entsprechen, also die ich wirklich gut standardisiert einkaufen kann, wo ich mich nicht differenziere, wie wir das so schön sagen in der Commerce-Welt über Customizing. Ich auch kein MVP oder kein 100-Tages-Launch von meiner Finanzbuchhaltung irgendwie plane. Doof ist natürlich, wenn ich in mein Warenwirtschaftssystem einkaufe und alles andere damit mache, als es eben als Standardsystem zu verwenden. Also wir sehen immer noch Projekte, wo tausende von Customizing-Tagen in so ein Wavi reingehen, wo man sich schon fragen muss, ist das eigentlich sinnvoll? Kann ich nicht für weniger Tagessatz in höherer Geschwindigkeit und auch in höherer Iteration meinen Custom-Geschäftsprozess eigentlich in einem Frontend-System abbilden? Da gibt es auch ein paar Beispiele dafür. Wenn ich plane, beides abzulösen, würde ich darüber nachdenken am Whiteboard, in dem Moment, wo ich sozusagen Scope und IT-Landscape zeichne. Wie abstrahiere ich Schnittstellen? Tipp 1. Welche Geschäftsprozesse gehören wohin? Was mache ich mit Order-Management? Was mache ich mit Produkt-Management? Was mache ich mit CRM? Was ist dann nach vorne raus das führende System? Das muss nicht binär sein, schwarz-weiß, 1-0, sondern man kann sich überlegen, im ersten Wurf ist es das, aber perspektivisch gehören die Daten da und dahin. Und dann kann man schon die Weichen richtigstellen. Aber ERP und Shop parallel einführen, Ampel rot.

Joel Kaczmarek: Gut, wir können immer Worst Practices ableiten. Also du sagst, das ist jetzt ein Beispiel für eine Parallelisierung, die du nicht vornehmen würdest, weil hoher Komplexitätsgrad.

Boris Lokschin: hoher Komplexitätsgrad, unmöglich zu debuggen, weil einfach der Fehler überall sein kann, unmöglich sozusagen die Fehler zu finden, maximaler Stretch für die Organisation, weil eigentlich so ziemlich jeder eingebunden ist und davon betroffen ist. Ampel auf gelb wäre bei einem anderen Beispiel, zum Beispiel Shop plus PIM, Produkt- und Informationsmanagement, ganz häufig ja auch gefordert und klingt ja erstmal total logisch, gerade wenn ich mit Herstellern und B2B-Unternehmen spreche, dann sagen die, Commerce kann ich machen, will ich auch, aber guck mal hier, meine Daten sind total Weil dünn sind alles irgendwie Artikelnummern und kryptische Bezeichnungen. Die Fotos von den Schrauben wurden auch noch nie geschossen oder ich habe da irgendwie nur ein Bild. Ich muss doch vorher erstmal meine Daten in Ordnung bringen. Von daher lasst mich doch erstmal das PIM-Projekt dann nochmal mit reindrücken, dann machen wir das zusammen. Da ist die Ampel auf gelb. Warum? Es ist nicht ganz so schlimm wie bei dem ERP. Deutlich weniger Stakeholder in der Company sind davon betroffen. Insbesondere natürlich Einkauf, vielleicht Kategorie-Management, Produkt-Management. Aber ich habe natürlich viele andere Prozesse nicht, die da reingreifen. Also es ist schon leichter zu isolieren. Es ist ein notwendiger Bestandteil. Also wenn ich sozusagen keine Daten habe, habe ich Schwierigkeiten, mein Frontend-System zu bauen. Auf der anderen Seite sind eigentlich fast alle modernen Commerce-Systeme auch mit PIM-Funktionalitäten ausgestattet. Also ich glaube, das Wort PIM verleitet die Leute dazu, zu komplex, zu groß zu denken. Viele haben ja die digitale Organisation gar nicht. Wenn du dann fragst, wie viele Leute habt ihr denn im Category-Management? Wie viele Leute werden die Produktdaten ändern, SEO-tauglicher machen?haben sie halt noch gar keine. Das heißt, für die geht es eigentlich darum,die Daten aus der WAVI zu nehmen, die drei Zeilen,die sie haben und sie halt nochmal anzureichern einmalig. Und das kann, glaube ich, so ziemlich jedes moderneCommerce-System out of the box. Wenn du halt eine größere Organisation hast,dann fangen Leute an, sowas wie Approvals und Workflows zu bauen. Der Joel legt das Initialprodukt an, dann geht das weiter. Boris edit die SEO-Daten, dann geht es weiter. Der Alex, der macht schöne Bilder. Gibt es jemanden, der die Bilder freigibtund dann gibt es nochmal jemanden, der die Bilderfür den Print-Kanal edit. Dann ist es ein Workflow, da gibt es Approval-Prozesse. Dann gibt es vielleicht Leute, die das irgendwie ganz, ganz schnell direkt im Frontend machen wollen. Also irgendwann kommt ein Threshold, an dem wahrscheinlich sich ein explizites System wie ein PIM dann auch rechtfertigen lässt. Und man sagt, okay, komm, jetzt machen wir das. Aber der Punkt ist bei ganz vielen nicht am Anfang des Projekts. Das heißt, man kann es parallelisieren, weil es isolierbarer ist. Muss man das machen? In ganz vielen Projekten auf jeden Fall erstmal Fragezeichen. Also stellt nicht die Frage, ob ihr ein PIM braucht, sondern stellt die Frage, welche Daten genau, Produktmanagement-Features genau benötigt ihr. Mit an Sicherheit grenzender Wahrscheinlichkeit werden diese Funktionalitäten verfügbar sein auch in euer Projekt. Ein Commerce-System, das heißt, das kann ein erster Schritt sein und das PIM kann man dann sauber nachziehen in einem Schritt zwei.

Joel Kaczmarek: So, jetzt wollen wir natürlich noch ein Beispiel für eine grüne Ampel.

Boris Lokschin: Genau, eine grüne Ampel, also was sich verhältnismäßig leicht umsetzen lässt und auch parallelisieren lässt, ist Shop und CMS. Erstmal ist das Content-Management-System relativ autark. Die Stakeholder in der Company sind auch relativ isoliert. Das sind meistens Leute, die im Marketing sitzen oder Content-Team sitzen. Die beiden Systeme haben jetzt erstmal per se nicht so super viele Schnittstellen untereinander. Wenn überhaupt, dann teilen sich vielleicht sowas wie einen gemeinsamen Login oder einen Customer Account, so ein Single Sign-On vielleicht. Das ist aber mittlerweile sehr, sehr einfach implementierbar. Die Content-Management-Systeme, wenn ich jetzt nicht natürlich an riesige Portallösungen denke und ich jetzt nicht gerade irgendwie ein Verlag bin, dessen Business das ist, Sondern wenn ich so an die typische Corporate-Webseite denke, ja, dann geht das verhältnismäßig einfach. Das Aber mittlerweile natürlich einfach aus Kundensicht, die Experience auch immer mehr zusammenfließt. Ja, sozusagen dieses Content und Commerce ist für den Kunden im Frontend nicht mehr so klar getrennt. Ja, wenn du auf einer Fashion-Seite unterwegs bist, ja, dann hast du eine gemischte Experience. Das heißt, du denkst ja nicht ins System als Kunde, ja, du bist einfach da. Guckst dir einen Banner an, liest vielleicht eine Story, guckst dir irgendwie Infos zum Hersteller, zum Material an, vielleicht irgendwie Models. Technisch gesehen geht man heute eben sehr stark dazu über, die Seiten aus den beiden Systemen im Frontend zusammenzubasteln, zusammenzustellen. Dann gibt es irgendwie ein führendes System, was die Seite technisch für dich aufbaut. Aber wenn du dir so eine Fashion-Seite vorstellst, dann ist das eigentlich so ein Flickenteppich aus einzelnen Blöcken. Dann kommt der Content-Block aus dem Content-System und vielleicht kommt die Produktempfehlung aus dem Commerce-System und der Header mit dem Warenkorb kommt auch aus dem Commerce-System. Wenn man sowas natürlich machen möchte, wenn ich wirklich eine CMS und Shop-Verzahnung maximal haben möchte, natürlich ein bisschen komplexer, dann ist es trotzdem noch parallelisierbar, weil ich das immer noch relativ gut aufbauen kann und auch die Integrationspunkte mittlerweile klar definiert sind. Aber es ist nicht mehr ganz so easy, wie wenn es zwei getrennte Systeme wären.

Joel Kaczmarek: Gut, also wir hatten jetzt einmal rote Ampel ERP und Commerce, wir hatten gelbe Ampel Shop und PIM und wir hatten die grüne Ampel Shop und CMS. Wir merken, wir sammeln ein bisschen Abkürzungen heute. Jetzt wäre es natürlich spannend, auch mal Best Practices abzuleiten. Also ich habe mir schon ein paar Notizen gemacht, fassen wir gleich mal zusammen, wenn wir abschließend zusammenlegen, was sind quasi so die Wege, die man gehen sollte, worauf kommt es an? Aber hast du mal auf der positiven Seite Beispiele, was so Best Practices sind, wenn ich Projekt Tetris spielen muss oder will?

Boris Lokschin: Also ich glaube, die erste wichtige Empfehlung ist das Thema Organisationslast beachten. Ich glaube, das ist auch ein gutes Auswahlkriterium dann für die eigenen Fähigkeiten, ob ich eben Parallelisierung oder eben Projekte sequenziell machen möchte. Wir hatten ja vorhin schon kurz darüber gesprochen, ja, Parallelisierung ist auf jeden Fall deutlich belastender, das heißt, wenn ich selber relativ dünn aufgestellt bin in meiner Organisation, nicht die Fähigkeiten und nicht das Budget habe, mich massiv mit extern zu verstärken, wenn ich viele andere Initiativen in der Company habe, das muss ja alles gar nicht IT- oder Digitalisierungsprojekt sein, ja, wenn ich einfach merke, die Marketing-Stakeholder, ja, die hier auch das Projekt natürlich mit begleiten müssten, ja, die Daten anreichern, die mit testen müssten, sind eigentlich noch mein, ja, wir haben jetzt gerade hier eine neue Kampagne oder eine neue Kollektion oder wir rollen gerade drei neue Länder aus. Oder meine IT ist gerade massiv überlastet, weil sie gerade irgendwie Händler onboardet oder an irgendwelchen anderen Schnittstellen schraubt und es ist eigentlich nicht wahrscheinlich, dass ich da substanziell Leute werde abzweigen können für ein bisschen zuarbeiten oder Fehler suchen. Dann ist, glaube ich, das Thema Paralysierung super schwierig. Da muss man einfach ganz ehrlich zu sich sein. Wie gesagt, man kann es kompensieren, gerade mit externen, vor allem im Bereich Projekt- und Programmmanagement. Das ist eine Rolle, die kann ich gut einkaufen, auch wenn es teuer ist. Um das hier direkt mal vorweg zu sagen, ist das etwas, was, glaube ich, ein smarter Move ist, weil die wenigsten Leute Migrationsprojekte vor allem gemacht haben. Noch weniger Leute haben parallele Projekte gemacht. Und noch weniger Leute haben sozusagen diese Parallelenprojekte auch noch zeitlich und budgetär übereinandergelegt, quasi in einem Programm. Also da muss man schon so ein bisschen in den Spiegel schauen und sich fragen, nur weil ich jetzt irgendwie mal den Relaunch meiner Webseite vor zwei Jahren betreut habe, ist es nicht, dass mich das befähigt, dazu ein komplexes IT-Programm zu führen in meiner Organisation. Das ist immer ein ganz guter Punkt, sich da Leute reinzuholen, die das einfach den ganzen Tag machen, die einfach schon zig Projekte gesehen haben. Nicht nur die Erfahrung mitbringen, sondern mir auch das Methodische und auch das Toolset an die Hand geben. Wie sehen Reportings aus? Wie behalte ich überhaupt den Überblick? Ich habe vorhin dieses Beispiel mit dem Zugschaltplan verwendet. Wie sieht sowas aus? Wie manage ich Abhängigkeiten zwischen den Projekten? Wann muss eigentlich wer was tun? Wie viel Puffer brauche ich? Monetär, budgetär? Wie tracke ich Budget? Da quasi zu experimentieren, ist glaube ich nicht so schlau. Das macht das Projekt unnötig teuer. Beachtet die Last, checkt, wie viele Ressourcen eure Teams parallel aufbringen können. Und man muss fairerweise sagen, in den allermeisten Fällen ist das ein großer limitierender Faktor. Man kann in eine Situation kommen, in der man es einfach machen muss, weil mein altes System wird abgeschaltet oder ich habe irgendwie massiven Druck nach vorne raus oder kostenmäßig. Aber macht euch da keine Illusionen. Also ein Parallelprojekt sauber durchzuziehen, ist schon die ganz große Kür. Von daher Tipp Nummer eins, beachtet die Organisationslast. Seid da ehrlich, kompensiert das mit extern, vor allem mit Projektprogrammmanagement, wenn ihr könnt. Seid euch aber auch darüber im Klaren, dass auch eure interne IT, Marketing, Sales, Business-Stakeholder, Einkauf auch Zeit einplanen müssen für Konzeption, für Planungsworkshops, für Testphasen und für andere Dinge.

Joel Kaczmarek: Jetzt hast du ja auch zum Beispiel einen Themenbereich aufgegriffen, diese Isolierbarkeit. Ist das noch so ein Best-Practice-Element, dass wenn man Isolierbarkeit hat bei Produkten, dass man dann hingehen kann und sie gut parallelisieren kann?

Boris Lokschin: Ja, also wenn ich wirklich isolierte Themen voneinander habe, wenn ich jetzt im Extremfall irgendeine App baue, die komplett losgelöst ist von meinem Commerce-Projekt oder von meinem ERP-Projekt, das senkt nicht die Last auf die Organisation erstmal, das senkt die Komplexität und das Risiko, weil ich muss dann immer noch zwei Projekte überwachen und zwei Projekte managen und zwei Budgets und zwei Timelines und zwei Anforderungsdokumente, aber ich muss zumindest diese nicht mehr miteinander koordinieren. Und das darf man nicht unterschätzen. Ich glaube, jeder, der so ein bisschen bei sich, ich habe jetzt beim Reinkommen gesehen, ihr habt ja auch da eine Taskwand, ja, und das sind ja auch Aufgaben und Abhängigkeit. Jeder, der so ein paar mehr Bälle in der Luft hält als nur einen pro Tag weiß, steigt die Komplexität ja sofort exponentiell. Das ist, wenn ich eben Dinge aufeinander abstimmen muss, genauso. Ja, ich muss ja nicht nur Dinge abstimmen, ich muss ja Leute aufeinander abstimmen, ich muss Personen. Am Ende sind es auch ganz banale Dinge, wie zum Beispiel sowas wie Urlaub. Ich habe ein Projekt und wenn ich ein großes Programm habe, bestehend aus mehreren Projekten, dann steigt natürlich die Wahrscheinlichkeit, dass Leute auch im Urlaub sein werden und dass sie immer dann im Urlaub sind, wenn es gerade nicht gut ist im Projekt. Es ist leichter, glaube ich, ein, zwei Leuten zu sagen, Jungs oder Mädels, ihr geht jetzt mal zwei Wochen später in den Urlaub, als wenn ich ein Programm habe, wo 30 Leute drin sind. Also die alle zu blockieren, am Wochenende mit einem Kumpel gesprochen, der hat drei Kinder. und der hat gesagt, der Sprung von zwei auf drei Kinder ist nicht bloß 50 Prozent, sondern dann steigt eigentlich alles exponentiell, weil ich kann dann drei Kinder nicht mehr zu zweit füttern, ich kann drei Kinder nicht mehr zu zweit baden, ich brauche auf einmal ein viel größeres Auto und so weiter. Das sind die ganzen Prozesse. Wir hatten eben dann auch deutlich komplexer und das ist dann hier genauso.

Joel Kaczmarek: Okay, man merkt ja auch so ein Stück weit, das zahlt irgendwie alles aufeinander ein oder es ist sehr voneinander abhängig. Also wenn du sagst, die Organisationslast musst du im Blick halten, dann guck dir mal auch die Isolierbarkeit der Units an. Dann hast du das Thema Komplexität. Du hast gesagt, Debugging ist ein Thema. Je mehr Komplexität, Verwobenheit, desto mehr Debugging-Schwierigkeiten habe ich. Externalisierbarkeit nimmt ab, wenn du sagst, okay, ich kann vielleicht meine Organisation entlasten, indem ich es auslagere. Aber wenn es komplex ist, kann das weniger Leute machen. Wie viele Akteure sind insgesamt davon betroffen? Also man merkt, das ist so ein bisschen so schnell toxisch.

Boris Lokschin: Genau. Das ist das Projekt Tetris, was man dann spielen muss. Die Klötze dann so legen, dass sie eben passen. Wie gesagt, es gibt auch kein Richtig, kein Falsch. Man muss eine realistische Selbsteinschätzung treffen. Wenn es meine Orga hergibt, dann geht der Weg, wenn ich feststelle, meine Orga gibt es nicht her und ich habe das Budget nicht für extern. Dann ist dieser parallele Zweig direkt weg. Dann kann ich mich gleich auf den Sequenzieren konzentrieren. Von daher ist es dann so in der Entscheidungsfindung relativ binär. Ich kann mich dann durch so einen Entscheidungsbaum fummeln und am Ende mich dann entscheiden für den ein oder anderen Weg.

Joel Kaczmarek: Trotzdem hast du auf mich den Eindruck gemacht, als es jetzt um das Thema Best Practices geht, dass du schon so zwei, drei große Achsen hast. Also deine erste große Achse war Organisationslast. Hast du noch weitere?

Boris Lokschin: Genau. Ich glaube, das Nächste, was man sich dann angucken muss, ist also Organisationslast, Programmmanagement. Also wenn ihr parallelisiert, ja, dann zentralisiert das. Ja, das bringt gar nichts, dann einfach drei Projektleiter einzusetzen. Es muss halt dann jemanden drüber geben, der Gesamtverantwortung für das Programm trägt, der auch die Übersicht trägt. Und das spielt auch so ein bisschen in den nächsten Empfehlungspunkten mit ein. Realistisches Reporting, ja, und auch Planung von Puffern und Buffern, ja. Ich glaube, in beiden Fällen, egal ob jetzt parallel oder sequentiell, was wir ganz, ganz häufig beobachten, ist, dass diese Projekte einfach von der Inception an, also so wie sie angelegt werden und so wie sie dann auch im Fortschritt intern reported werden, also reported werden dann meistens solche Dinge wie Budget, Scope, Zeit einfach komplett falsch aufgesetzt. Also entweder habe ich gar keine Visibilität, so klassische Projekt-Health-Checks, wo ich einmal in zwei Wochen sehe, wie ist mein Burn-Down, also wie viel Scope habe ich runtergebrannt, wie komme ich auf der Zeitleiste voran, wie Wie sieht es im Budget aus? Das sind so die mindestens drei Kurven, die ich mir eigentlich immer angucken sollte, wenn die nicht unbedingt aligned sind. Beispiel, nach der Hälfte der Zeit habe ich schon 90% des Budgets verbraucht, aber nur 20% des Korbs geschafft. Das ist dann relativ klar, dass das Projekt im Argen ist. Oder umgekehrt, die Hälfte der Zeit ist weg, aber ich habe schon 80% der Sachen geschafft und ich bin bei 30% des Budgets. Das Projekt ist wahrscheinlich super unterwegs. Von daher, diese drei Kurven muss man sich angucken. Gerade im Programmmanagement brauche ich natürlich auch mehr Visibilität auf Abhängigkeiten und das ist eben wirklich ganz häufig eben nicht da. Die Dependencies zwischen den Projekten und auch das Thema Buffer. In jedem Projekt, was wir sehen, unterschätzen die Leute das massiv, wie viele Dinge dann am Ende doch nicht nach Plan verlaufen. Egal wie gut das Projekt aufgesetzt ist, es sind Menschen, Leute werden krank, Leute fahren in Urlaub, Schnittstellen werden nicht rechtzeitig fertig, man hat Abhängigkeiten von Lieferanten, von anderen Dienstleistern, von irgendjemandem, der irgendjemand eine Spezifikation schicken will, du hast irgendwie einen Task, der ist total simpel, du musst mit irgendeiner Standardschnittstelle integriert, du brauchst eigentlich nur das Dokument, der Partner bei deinem Paymentanbieter ist aber jetzt gerade Vater geworden.und ist drei Wochen wegund selbst nach drei E-Mailshast du das Dokument noch nicht. Und plötzlich gerät der Task in Verzugund dadurch schiebt sich dann der Testplan. Das ist dann wie so ein kaskadierender Effektdann auf den ganzen Projektplan. Die Leute, die du geplant hast,die das dann und dann testen,können es nicht mehr testen. Die Leute, die den End-to-End-Prozessder ganzen Bestellung mit Payment Rückgabe irgendwie vertesten sollten, können sie auch nicht. Du kannst andere Dinge nicht anfangen. Und das passiert. Und das passiert immer. Auch Dinge, die komplett normal sind und auch technische Probleme gibt es mal. Und da sind die Projekte einfach alle viel zu optimistisch. Wenn ich da nicht mindestens mit, je nach Komplexität, mit irgendwie 20 Prozent auch an Budget-Buffer reingehe, in komplexen Fällen vielleicht auch mal 30, 35 und mir sage, das Budget, damit sollten wir planen, Wir sollten dagegen managen, dass das nicht oder nicht komplett gebraucht wird. Aber wenn ich reingehe und meine gesamte Projektorganisation ist darauf aufgebaut, dass ich so eine Punktlandung hinlege, das ist sehr, sehr schwer möglich. Es sei denn, ich bin eben massiv bereit, auch dann an der Scope-Schraube zu drehen, sodass dann der Programm- oder Projektmanager auch Dinge wieder fallen lassen kann und sagen kann, okay. Man sagt immer so ein bisschen, ich kann ein Tod sterben, wenn ich so dieses Dreieck habe aus Scope, Budget und Zeit, so zwei von drei kann man immer schaffen, ich kann dann versuchen sozusagen die Zeit zu halten, das Budget, dann muss ich ja beim Scope cutten. oder ich kann sagen, okay, den Scope liefere ich in der Zeit, dann kostet es halt einfach mehr Geld. oder den Scope liefere ich und beim Budget bleibe ich, dafür muss ich das vielleicht ein bisschen strecken, also zwei von drei Ecken der Pyramide kann ich immer schaffen, im guten Fall, aber nicht alle drei. Diese Illusion wird leider eben auch ganz häufig dann auch den Stakeholder intern erzählt. und wenn ich dann sehe, schon in der ersten Projektwoche, Projektiteration, wie dann das Reporting aussieht, wie die Formate aussehen, dass da kein Buffer geplant ist, dann bin ich sofort im roten Projekt, obwohl es eigentlich erst in der ersten Woche ist.

Joel Kaczmarek: Gut, also wir fassen nochmal ganz kurz zusammen. Unsere Best Practices in Sachen Projekt Tetris waren jetzt Organisationslast im Blick behalten, möglichst zentralisieren, dann sich Puffer lassen und du hast gesagt, realistisches Reporting mit sinnvollen Metriken. Also, wie gesagt, Burndown, Budget, Zeit. Noch was vergessen?

Boris Lokschin: Genau, dieses Alignment der Stakeholder ist ein Problem, was wir ganz, ganz häufig sehen. Was meine ich damit? Ich habe hier in dem Projekt unterschiedlichste Level an Leuten, die beteiligt sind. Das geht damit los, dass ich diverse Abteilungen habe, die ich zu koordinieren habe, die auch alle ihre eigenen Prios haben und nur weil ich jetzt hier der Projektleiter bin für das Commerce-Projekt und eigentlich so einen vertikalen Schnitt durch deren Departments mache, Heißt das nicht, dass die alles andere liegen lassen? Das heißt, ich muss zusehen, dass diese Leute abgeholt sind, dass die on board sind, dass die Ressourcen planen für mich, dass die wissen, was, wie, wann passiert. Muss natürlich irgendeine Steuerungsinstanz haben, also meistens nennt man das Steering Board oder Steering Committee oder Lenkungsausschuss, indem ich weniger regelmäßigen Abständen, zum Beispiel einmal pro Monat, auch übergeordnet, ja, meinem Management,meinen Eigentümern den Projektfortschritt zeige. Ja, jetzt nicht auf operativer Ebene,wo ich über einzelne Tasks spreche,aber sowas wie eben so ein Burndownist eigentlich eine gute Best Practice. So dann, guck mal Joel, du bist jetzt hierder CEO von der Company, ich bin der Projektleiter,der Projektleiter von dem Commerce-Anbieterist mit drin vielleicht, ja, oder der Projektleitervon der Agentur, die das Projekt vielleichtmit mir gemeinsam umsetzt, ist mit drin.dass alle diese operativdas Projekt nach vorne treiben. So idealweise sind diese Leute auch aligned. Das kommt auch ganz häufig vor,dass sie es eben nicht sind,dass der Projektleiter von der Agentur sagt,das Projekt ist dufteund alles ist on track. Du bist aber der interne Projektleiterund du findest das überhaupt nicht komisch. allesund dein Gefühl, dass nichts funktioniertund du hast schon drei, vier Sprintsübergeben bekommenund die sind alle noch nicht komplettund irgendwie fühlt sich das allesnoch total roh an. Sowas ist natürlich dann tödlich, wenn in so einem Steering Board dann schon da die Meinungen auseinander gehen. Aber vorausgesetzt, man ist aligned, dann präsentiert man eben, wie ist der Outlook. Gibt es Probleme, die man auf operativer Ebene vielleicht nicht lösen kann? So ein Steering Board kann zum Beispiel gut dabei helfen, Budget- oder Change-Request-Themen aufzugreifen. Ganz viele, gerade die Projektleiter, müssen ja miteinander über Monate hinweg operativ arbeiten. Leben also natürlich auch davon, dass es irgendwie eine gesunde Arbeitsatmosphäre gibt. Wenn ich mich natürlich mit meiner Agentur schon in der zweiten Woche total verkrache und man eigentlich nur noch gegeneinander arbeitet und nicht mehr miteinander und um jeden Change Request und jeden Montag fightet, als wenn es irgendwie das letzte Hemd wäre, das ist natürlich doof. Das kann man dann viel leichter in so ein Steering Board tragen und quasi die Entscheidung einfach anderen überlassen und sagen, guck mal, da gibt es hier zwei verschiedene Perspektiven drauf. Ich bin der Meinung, das hatten wir besprochen. Er ist der Meinung, das hatten wir gar nicht besprochen. Was machen wir damit? Und dann können dann die Geschäftsführer vielleicht der Partei irgendwie einen Kompromissvorschlag erarbeiten. Also Steering Boards. Auf operativer Ebene gibt es auch einen Begriff, der heißt War Room. Also wirklich so War wie Krieg. War Rooms sind immer ganz gut, wenn man in einer kurzen Zeit alle Leute mal an einen Tisch bekommen möchte. Heute ist ja dezentrales Arbeiten total in. So diese Zeiten, in denen man gesagt hat, okay, meine Agentur oder mein Implementierungspartner, der hat hier auch in Berlin zu sitzen, am besten in der nächsten Straße, ist eigentlich auch vollständig. Das heißt, ich habe meistens meine eigene Organisation, die ist vielleicht auch schon mal verstreut über drei, vier. Meine IT sitzt da und meine Marketing sitzt da und dann habe ich vielleicht noch ein paar Ländergesellschaften. Meine Agentur sitzt in der Zentrale in Berlin, hat aber noch ein paar Leute in Polen, die dann nochmal zuarbeiten und nochmal irgendwie drei Remote Rockstar Developer aus Barcelona, die da zugeschaltet sind. Und das ist auch alles fein. Ich glaube, mittlerweile mit Zoom, Slack und den ganzen anderen Methoden ist das alles möglich. Aber am Ende des Tages, gerade in den letzten Projektwochen, wo nochmal der Feinschliff gemacht werden muss, wo man in kurzer Taktfrequenz Dinge testet, Daten importiert, die Performance optimiert, nochmal sozusagen die alten Systeme abschaltet, nochmal End-to-End-Tests macht, ist es total modern geworden, einfach so Warrooms zu machen. Da kommen Leute, so für die letzten zwei Wochen sitzen wir jetzt alle hier an einem Tisch in einem großen Raum in Berlin. Kurze Wege, kurze Kommunikation, einmal über den Tisch, keine Tickets, kein Slack, kein Overhead. Wir starten schrubben das jetzt hier runter, machen das gemeinsam, sind auch alle motiviert, essen, trinken, atmen alle das Gleiche, schlafen zur gleichen Zeit, ziehen das jetzt durch. Also War Rooms für operative Teams, Tiercos für übergeordnete Themen und wirklich sozusagen die Stakeholder sauber abholen, also saubere Capacity, Ressourcenplanung, Urlaube, Krankheit als Variable einplanen, also nicht einfach nur in 10 FTE rechnen, sondern davon ausgehen, dass die Leute auch krank sein werden, dass ich eben nicht 10 mal 5 Arbeitstage mal zur Verfügung habe im Projekt, sondern dass ich dann vielleicht nur 0,9 oder 0,85 zur Verfügung habe. Das sind so Dinge, damit kann man sich von vornherein schon zumindest im Plan deutlich realistischer aufstellen. Später wird es trotzdem so sein, dass der Plan eben nicht eins zu eins umgesetzt wird. Das heißt also, ich muss darauf gefasst sein, dass egal wie gut der Plan ist, es wird irgendwie Themen geben und die wird es dann eben zum Managen geben.

Joel Kaczmarek: Lerne ich daraus, wenn du sagst, gerade wenn es um Alignment und Koordination geht, vielleicht auch mal Abteilungen, die auch noch andere Sachen zu tun haben, als so einen Relaunch zu begleiten, dass eigentlich so Inzentivierung auch so ein Punkt ist, den ich aktiv angehen sollte?

Boris Lokschin: Ja und nein. Also ich meine, grundsätzlich ist das ein bisschen schwierig. Ich kann natürlich über OKRs oder über andere Maßnahmen, ja, die ganze Organisation auf sowas intensivieren, sehe ich jetzt in der Realität selten, ja. Also dass man da quasi der ganzen Company ein Target gibt und sagt, wir wollen jetzt dieses Commerce-Projekt oder das PIM-Projekt erfolgreich stemmen und da gibt es jetzt irgendwie einen Bonus für, sieht man eher selten, ja. Also was man schon oft hat, ist auf der Projekt-Programm-Management-Seite, gerade mit extern, ja. Also wenn dann die Management-Berater reinkommen, da kann man schon gut die vergeben und irgendeine Möhre, Auch das muss smart gewählt sein. Also ich habe viele Projekte gesehen, wo gute externe Programme oder Projektmanager reingeholt wurden und dann wurde denen dann eben knallhart gesagt, du hast jetzt hier das Budget drunter zu managen. Wenn sie vorher den Budgetplan selber erstellt haben und dann schlau genug waren, sich die nötigen Puffer, also das, was man Contingency nennt, Abschläge für Krankheiten, für vielleicht auch Hirings, wenn sie dann innerhalb des Projekts auch noch zu passieren haben, reingebracht haben, da kann man das machen. Wenn ich natürlich vorher einen Budgetplan aufgestellt habe und dann sage, Joel, das ist jetzt der Plan, den managen wir jetzt knallhart runter, passieren zwei Sachen, entweder ist der Plan Bullshit gewesen oder der Plan ist Bullshit gewesen und du bist ein Arsch. Was machst du dann? Du exekutierst den Plan einfach eiskalt. Nach dem Motto, nach mir die Sintflut, ja, und ich bin ja eh weg und ich muss hier mit keinem Freund sein, verbrenne ich einfach alle Leute, ja. Das heißt, ich manage das eben knallhart, ja, ich drücke, ja, die Dienstleister bis zum Gehtnichtmehr, ich drücke die internen Mitarbeiter, idealerweise natürlich auch noch mit der internen Macht ausgestattet, das zu tun, bringe ich das Projekt einfach über die Bühne, so. Dass das nicht nachhaltig ist, nicht gut funktioniert, dass die Leute da keinen Bock drauf haben, ja, und in welcher Qualität dann Dinge abgegeben werden, ist, glaube ich, relativ klar, aber man sieht das tatsächlich häufig, ja, also wenn die Anreizinstrumente falsch sind, kann es halt auch mega nach hinten losgehen, von daher vergibt gerne einen Bonus an jemanden, ja, wenn er das gut managt, aber gibt ihm auch die Chance vorher professionell an dieser Planung zu partizipieren, weil die Person ist nach sechs Monaten weg und du hast die Agentur noch drei Jahre bei dir, ja, und die Software fünf, ja, und dein Team will es eigentlich auch noch behalten und nicht, dass sie alle wegkündigen und im Burnout verschwinden.

Joel Kaczmarek: Dann lass uns doch mal abschließend so eine Art Handlungsempfehlung geben. Also wie würdest du so Projekt Tetris angehen? Wir haben gelernt, es ist ein bisschen wie bei den Anwälten, das kommt darauf an, ist ja immer so der Lieblingssatz von denen. Also man sollte so ein bisschen unter die Haube gucken, wo steht die eigene Organisation? und ich fand dieses Dreieck auch ganz plausibel, was du gesagt hast aus Scope, Fokus, Budget und Zeit. Aber was wären so abschließend deine Tipps, wie man sowas angehen sollte?

Boris Lokschin: Ich würde mich wirklich heransetzen und in den allermeisten Fällen, wenn ich nicht den unbedingten Zeitdruck habe, weil mein bestehender Dienstleister, mein bestehendes System abgeschaltet wird oder weil ich Business-Ziele habe, die sonst gar nicht realistisch erreichbar sind. Ich würde dieses Parallelisieren von Projekten eher als Randcase sehen. Ich glaube, ich würde immer nach einem smarten Weg suchen, sequenziell, aber in kurzen Iterationen, also mit schneller Geschwindigkeit, mein Re-Platforming zu machen. Das macht es für die meisten Leute leichter. Ich habe weniger Stakeholder, ich habe ein bisschen weniger Interessenten. eine Organisationslast. Ja, es dauert am Ende vermutlich länger, ein bisschen länger. Dafür kann ich aber leichter Fehler suchen. Das Team ist einfach weniger gestresst und meine gesamte Orga ist weniger gestresst. Also ich würde sehr stark challengen. Erstmal habe ich eine Need für ein Parallelprojekt? Ja, nein. Und dann ausgehend eben von der Entscheidung schauen, dass ich meine Organisationsfähigkeiten checke und auch am Ende mein Budget. Was möchte ich in welchem Budget auf die Straße bringen? Ein letzter Tipp, sequenzielle oder parallele Projekte auch noch zu paaren mit internem Organisationsaufbau. Das ist die Kür im Quadrat. Also wenn ich das noch mache und sage, ich möchte eigentlich den Shop relaunchen und danach das CMS oder vielleicht auch beides. Gleichzeitig habe ich eine Agentur und einen externen Projektleiter, der mir dabei helfen soll. Am besten möchte ich auch noch parallel schon mal anfangen, mein Team von den zehn Leuten zu heiern. Und idealerweise, damit die Kosten auch noch richtig geschont werden, baue ich von vornherein einen Bullshit-Bingo-Plan, in dem ich schon mal die Leute, die noch gar nicht da sind, für die ich noch gar keine Stellanzeigen habe, schon eingeplant sind. Das heißt, nach drei Monaten kommt ja der erste und nach vier Monaten kommt dann der zweite und nach fünf Monaten kommt der dritte. Und Zug um Zug plane ich bei der Agentur die Leute schon mal vorsorglich mal raus, um einfach mal einen schönen Budgetplan zu haben, um dem Management zu zeigen, guck mal, externe Kosten werden hier durch interne ersetzt und zum Ende des Projekts geht die Agentur nach Hause, zufälligerweise am letzten Projekttag und mein neues, frisch gerammt abtes Team von fünf Leuten steht dann Gewehr bei Fuß. Das ist natürlich aus Grimms Märchen abgeschrieben und funktioniert in der Realität absolut gar nicht. Ich kann das machen, ich kann mir das vornehmen, aber trennt diese Zweige. Der Organisationsaufbau, das ist noch schwerer vorhersagbar, noch schwerer vorkastbar. Ihr könnt weder genau sagen, wann die Leute kommen, noch welches Level sie haben, noch ob sie sofort mitarbeiten können. Ihr könnt mega Glück haben und den Top-Spriker-Experten finden, der sofort im Projekt mitarbeitet. Aber ihr könnt auch einfach einen guten PIP-Mann finden, der vielleicht erstmal gerammt abwehren muss. Also tut euch einen Gefallen, verwurschtelt das nicht und plant nicht Armeen, die euch noch gar nicht zur Verfügung stehen. Das wird nicht dazu führen, dass das Projekt erfolgreich ist.

Joel Kaczmarek: Hast du so eine Top 3 an Problemen, die du immer beim Projekt Tetris beobachtest?

Boris Lokschin: Ich glaube, mit großem, großem Abstand auf jeden Fall Visibilität. Ja, das ist, glaube ich, das, was man einfach am häufigsten sieht. Wie eingangs gesagt, die meisten haben eben Schwierigkeiten, ein normales Projekt zu managen. Also zu managen heißt, tagesaktuell die Übersicht zu haben. Wo steht das Projekt? Welche Stolpersteine gibt es? Ja, was ist auf dem kritischen Pfad? Umso komplexer es wird, umso weniger Visibilität hat man da. Ja, wenn man da auch reingerufen wird, manchmal so von außen und Leute sagen, das Projekt läuft nicht, dann merkt man, Mist, da gibt es noch nicht mal das Fundament, um da mal eine vernünftige Analyse zu machen, ja. Das zweite ist, ich glaube, die technischen Abhängigkeiten der Technologie-Zoo wird halt auch unterschätzt. Ich meine, Technologie wird immer komplexer. Ich habe vorhin schon gesagt, wenn ich so einen ERP und einen Shop mache, muss ich mir heute teilweise Gedanken darüber machen, auch wenn ich es nicht parallelisiere. Wo gehört was hin? Wie sind sie miteinander integriert? Also ich muss so zwei, drei Schritte nach vorne denken. Habe aber gleichzeitig das Problem, dass gerade im Frontend, an den Kundensystemen entlang, sich alles so schnell verändert. Wenn ich jetzt überlege, so ein System wie zum Beispiel Spryker, was dann API-basiert ist, Headless ist und das macht es ja noch schwerer. Da gehe ich rein und überlege mir, okay, was heißt das denn? Muss ich da nicht ein Frontend parallel noch anbinden? Kann ich erst mal mit dem starten? Was ersetze ich dann hinterher? Und wenn ich dann so zwei, drei Technologie-Stacks noch zu mischen habe, das macht es nicht leichter. und da fairerweise, es gibt auch nicht allzu viele Leute, die mit sowas Erfahrung haben. Also da nehme ich automatisch einfach ein größeres Risiko auf mich. und Der letzte Punkt ist, aus den Best Practices vorhin, also wirklich absolut banal, aber so dieses Nicht-Alignen, dieses Nicht-Vorher-Abstimmen, also du glaubst gar nicht, wie viele Pläne wir sehen, wo du, wenn du da einmal draufkommst, sagst, okay, Urlaube nicht geplant, ja, Krankheiten nicht geplant, Verfügbarkeiten von Leuten nicht abgestimmt. Weiß denn Finance überhaupt, dass wir in zwei Wochen einen End-to-End-Test vom Shop fahren, dass sie eigentlich alle Zahlungsvorgänge, alle Zahlarten, das Buchen, das Zurückbuchen, Retouren, dass sie das zu checken haben, haben die dafür Ressourcen geplant? Oh, nee, ja, haben wir denen noch nicht gesagt. Okay, alles klar. Wie realistisch ist das, dass sie das machen werden? Du möchtest anbinden an deine Warenwirtschaft. Weiß die IT, dass sie ein Testsystem für die WAVI bereitstellen müssen? Du kannst ja nicht an das Live-Warenwirtschaftssystem anbinden. Das heißt, du brauchst irgendeinen Staging-System, irgendeine Sandbox, mit der du experimentierst. Wissen die das? Haben die dafür Bandbreite? Haben die dafür Lizenzen bestellt bei dem Hersteller? Haben sie dafür die Kapazität, dir eine Sandbox hinzustellen, die zu konfigurieren, dass das nicht irgendein Dummiesystem ist, sondern am besten eigentlich dein System? Ach nee, ja, haben wir auch nicht mit denen besprochen, ja. Auch wenn es total banal ist, dieses Alignment von Stakeholdern, dieses rechtzeitige Bestellen von Ressourcen, total wichtig. Also auf der einen Seite ist das so ein bisschen traurig, weil die Dinge sind relativ einfach. Das ist jetzt kein, ich muss mit den Leuten sprechen, ich muss mir irgendwie einen Projektplan überlegen, ich muss den Fortschritt tracken. Von daher, das ist sozusagen die Good News, dass das eigentlich leicht fixbar ist. Die Bad News ist tatsächlich, 95% der Projekten ist das nicht sauber aufgesetzt. Und das führt dann dazu, dass ich unabhängig davon, ob parallel oder sequenziell, einfach Schwierigkeiten habe und sich sowas dann zieht.

Joel Kaczmarek: Vielleicht letzte Frage zum Thema. Wir haben ja ganz viel geredet über Mitarbeiter, der muss das wissen, der muss jenes wissen, hat der jene Kompetenz. Was ist denn eigentlich so ein Personenprofil, was ich mir warm halten sollte, akquirieren sollte, im Blick haben sollte, wenn es um so Projektmanagement auf so einem Level geht?

Boris Lokschin: Das ist wirklich ein generisches IT-Projektmanagement-Profil. Ja, Leute, die einfach je nach Methode, mit der ich arbeiten möchte,wenn ich moderner unterwegs bin,mit den agilen Methoden Erfahrung haben,wenn ich etwas klassischer unterwegs bin oder sein muss,ja, da gibt es eben auch andere Projektmethodiken. Ich glaube, ich sollte darauf achten,dass derjenige wirklich die Domäne auch versteht,ja, ich meine, wenn er jetzt immer nur Projekteim Bereich Kassensysteme gemacht hat, ja, Es gibt schon viele inhaltliche Details. Ich habe externe Projekt- und Programmmanager erlebt, die vom Fach waren, die einfach in diesem Umfeld Projekte gemacht haben, das heißt, die auch inhaltlich verstehen, was dort passiert, die inhaltlich die Abhängigkeiten verstehen, die auch verstehen, was auf dem kritischen Pfad ist, die das auch challengen können, die auch die einzelnen Projektteams, die ja dann auch wie so kleine Staaten in sich versuchen, sich schön zu reporten, der das in Frage stellen kann und sagen kann, hey, das kann doch gar nicht sein, warum ist das nicht fertig? Sowas hilft enorm. Also da würde ich auf jeden Fall darauf achten, dass derjenige Erfahrung hat in dem Space, viele Projekte gemacht hat. Ich würde mir die Sachen zeigen lassen. Ich würde mir zeigen lassen, wie arbeitet er oder sie, was ist das Toolset, was ist das Reporting Framework, was er mitbringt. Kaum eine Rolle ist so gut extern referenzierbar wie die. Das heißt, ich würde mir immer die zwei, drei Reference Calls geben lassen von demjenigen und einfach auch mit den vorherigen Kunden oder Partnern telefonieren und sagen, guck mal, der Joel, der sagt hier, der hat bei dir die zwei Projekte gleichzeitig gemacht oder sequenziell gemacht, hat sich da massiv entlastet, hat das in Time und Budget geliefert, ja, oder hat das vielleicht nicht im Budget geliefert, aber hat da die Eskalation sauber gemanagt, hat da nochmal sieben externe Dienstleister mitgesteuert. War das so? Würdest du ihn nochmal nutzen? Würdest du ihn empfehlen? Was hat gut funktioniert? Wie hat das auf der persönlichen Ebene funktioniert? Wie ging er in Konfliktsituationen um? Was hat das Team über ihn gesagt, als er weg war? Haben sie gesagt, puh, endlich ist er raus? Oder gesagt, Mensch, hier ist das Kartenaussamm gebrochen, weil er hier die einzige Struktur reingebracht hat? Also das kann man relativ leicht und gut extern referenzieren.

Joel Kaczmarek: Hervorragend. Dann hoffe ich, dass viele, die jetzt hier zuhören, ihr Tetris ein bisschen besser gemanagt kriegen. Und Viererleinen muss man ja immer schaffen bei Tetris. Vielleicht gelingt das dem einen oder anderen. Wie immer war es ein spannender Ritt mit dir. Finde ich dir ganz herzlich. Danke.

Boris Lokschin: Vielen Dank.