{"id":4191,"date":"2022-01-04T08:51:00","date_gmt":"2022-01-04T07:51:00","guid":{"rendered":"https:\/\/codify.in\/?p=4191"},"modified":"2022-09-19T18:08:36","modified_gmt":"2022-09-19T17:08:36","slug":"innovationsprojekte-neben-tagesgeschaeft","status":"publish","type":"post","link":"https:\/\/codify.in\/de\/2022\/01\/04\/innovationsprojekte-neben-tagesgeschaeft\/","title":{"rendered":"Innovationsprojekte mit Leuchtturmcharakter tageweise neben Kerngesch\u00e4ft vorantreiben?"},"content":{"rendered":"

Wir konnten im letzten Jahr wieder beobachten, was passiert, wenn ein fachübergreifendes Innovationsteam nicht für die gesamte Dauer eines Projektes freigestellt werden kann, man sich aber mit den Fachbereichen und entsprechenden Führungskräften auf einen “Kompromiss von zwei Tagen die Woche” einigt. Klingt erst mal gut und wurde von allen Beteiligten beteuert, dass die Zusage eingehalten wird. Die Realität jedoch sah so aus: Manche Teammitglieder hatten dann statt zwei Tagen, effektiv ganze zwei Stunden pro Woche, die Sie dem Projekt widmen konnten.<\/p>\n\n\n\n

Doch zunächst etwas Kontext: das Unternehmen ist eine klassische Ingenieurs-getriebene »Command-Control« Organisation mit vielen historisch (auch durch Zukäufe) gewachsenen BUs, die, so kann man sagen “recht Silo-artig operieren”. Für eine existierende technische Lösung einer BU sollten potentielle Neukunden, ein überzeugendes, anvalidiertes Wertversprechen sowie ein Geschäftsmodellkonzept entwickelt werden (Customer Discovery). Der hochengagierte, und von agilem Arbeiten überzeugte, Projektsponsor stimmte sich dafür mit Führungskräften aus anderen Bereichen ab, ihm für 12 Wochen, jeweils einen Mitarbeiter mit entsprechendem Kompetenzfokus (Design, Accounting, Engineering, etc.) für das Team abzustellen. Man einigte sich auf besagte zwei Tage pro Woche — frei einteilbar durch den entsandten Mitarbeiter. Die entsendenden Führungskräfte und der Rest der Organisation hatten zum Zeitpunkt der Zusage keine Erfahrung mit agilen Arbeitsweisen und nicht-technischem Innovationsmanagement (Business R&D). Auch ein Denken in Service Design<\/a> oder Geschäftsmodell-Logik war nicht existent.<\/p>\n\n\n\n

Das Projekt startete vielversprechend: Talent, Drive und Lernwille waren im Großteil des Teams eindeutig vorhanden. Eine Offenheit für ein Reframen und Explorieren von Opportunitäten außerhalb der Ausgangschallenge waren beim Projektsponsor — seines Zeichens Geschäftsführer einer wichtigen BU — vorhanden und somit bestand für das Team zumindest von seiner Seite auch spürbar psychologische Sicherheit<\/a>. Aber schon in den ersten Wochen des User Research wurde klar, dass das Team nicht einmal zu den Ritualen vollzählig zu erscheinen vermag. Gründe: “Bei uns im Bereich brennt gerade die Hütte.”, “Da haben wir eine andere, wichtige Veranstaltung”, “Sorry, aber mein Chef [Grund hier einfügen]”<\/em>. Aus zwei Tagen pro Woche effektiv verfügbarer Kapazität für das Innovationsprojekt wurden somit zum Teil nur besagte zwei Stunden [sic!].<\/p>\n\n\n\n

Wir haben dies selbstverständlich in unseren Retros reflektiert und die Teammitglieder versuchten sich ggü. ihren Vorgesetzten für das Projekt stark zu machen und es mehr zu priorisieren. Jedoch wurde es sowohl aus Sicht der Vorgesetzten als auch einzelner Teammitglieder immer wieder herabpriorisiert.<\/p>\n\n\n\n

Eines vorab: Nichts davon hat uns als Innovationscoaches überrascht. Wir kennen die Effekte von Incentivierungskonflikten; anfänglichen Missverständnissen, was agiles Arbeiten bedeutet; oder auch dem hohem Workload im Kerngeschäft mit Tendenz von Führungskräften Moonlighting<\/a> für „derlei Seitenprojekte“ zu erwarten, etc.<\/p>\n\n\n\n

Die Frage, die mich aber umtreibt ist: Wie können wir einem solchen Team helfen, damit die entsendenden Führungskräfte ihre Zeitzusagen einhalten?<\/strong> Und noch einmal: Kontext ist eine nicht-agile Organisation, die kein Verständnis für die Bedürfnisse erster “Versuchskaninchenteams” hat. In den meist auf lokale Maxima optimierenden Silos\/BUs besteht kein geteiltes Interesse am Erfolg des Projektes.<\/strong> Weiters ist die Organisation weit davon entfernt sich für die systemischen Zusammenhänge eines gut abgestimmten Innovationsmanagements<\/a> geschweige denn Organisationsdesigns zu interessieren. Auch ist der Projektsponsor auf die Kooperationsbereitschaft seiner Managerkollegen angewiesen und kann diese zu nichts „zwingen“. Es geht hier also darum in einem beschränkten Kontext ohne langfristig angelegte Change- oder Transformationsprogramme einfach ein erstes bereichsübergreifendes Innovationsprojekt durch “die Ziellinie” zu bekommen<\/strong>. Denn — typisches Henne-Ei Problem — der Projektsponsor glaubt (zu recht in diesem Kontext), dass der Rest der Organisation sich für die Vorteile dieser Art des Arbeitens erst interessieren wird, wenn er ihr ein erfolgreiches “Leuchtturmprojekt” vorzeigen kann.<\/p>\n\n\n\n

Ich weiß, dass dies ein sehr spezieller Fall ist und sicher viele von Euch sagen werden, dass es die beste Lösung wäre, in solch einem Projektsetup ein Team gar nicht erst starten zu lassen oder erst (Awareness)Arbeit am System zu leisten sei. Aber es ist nun einmal die Realität in weiten Teilen der deutschen Wirtschaft<\/a> (siehe auch dieser gute Artikel von Patrick Stähler von 2001<\/a> [sic!]), dass die ersten agilen Projektversuche alles andere als ideal verlaufen. Ergo müssen Teams unter den Startbedingungen arbeiten, die deren Organisation vorgibt. Und die sind dann auch in 2021 immer noch so wie in diesem Bild:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Darum interessieren mich zwei Dinge: 1) Wer von Euch hat schon mal in so einer Situation gesteckt und was habt Ihr getan um Teamkapazitätsprobleme durch uneinsichtige<\/s> Kerngeschäfts- und Silo-incentivierte Linienmanager beim nächsten (imperfekt aufgesetzten) Projekt zu vermeiden? 2) Was haltet Ihr von unten stehender Verpflichtungserklärung<\/a> für die entsendenden Führungskräfte? Was spräche dafür, eine solche beim nächsten Projekt einzusetzen, was dagegen?<\/strong><\/p>\n\n\n\n

Ich freue mich über Eure Kommentare hier im Post<\/a> oder an folgender LinkedIn-Diskussion: <\/p>\n\n\n\n