Agile PEP Minds 2018 – ein Rückblick

Auf der Agile PEP Minds in Berlin trifft sich Jahr für Jahr das Who-is-Who der agilen Entwicklung physischer Produkte. Aus der Perspektive eines Innovations-Experten, der aus der „alten“, klassischen Stage-Gate Welt kommt und gerade in die Agile Community hineinwächst, stellt sich mein Konferenz-Rückblick wie folgt dar.

Die Kurz-Zusammenfassung
• Vertreter der akademischen Welt haben mit frischen Studien nachgewiesen, dass agiles Entwickeln gute Resultate bringt und somit eine Daseinsberechtigung hat.
• Unternehmensvertreter haben berichtet, dass die agile Transition bei ihnen in vollem Gange ist, das Etablieren des „richtigen Systems“ aber so seine Tücken hat, und sie noch ein Stück Weg vor sich haben.
• Berater haben vermittelt, dass sie wissen, wie die agile Transition erfolgreich wird, und wie man Schwierigkeiten und Fallgruben umgehen kann.

Die inhaltlichen Höhepunkte

• Ja! Agiles Entwickeln erzielt sehr gute Ergebnisse …
Praktische Erfahrungen und wissenschaftliche Studien zeigen, dass die Vorteile des agilen Entwickelns primär in weichen Faktoren, wie z.B. Transparenz, Motivation der Teammitglieder, Kommunikation im Team liegen. Bei harten KPIs wie Durchlaufzeit des Projekts oder Entwicklungskosten bleibt agiles Entwickeln noch hinter den Erwartungen zurück. Über die Zeit werden die weichen Faktoren die direkt messbaren Ergebnisse positiv beeinflussen – so die Vermutung.
… aber verglichen womit? Die Agile Community wähnt im Wettstreit mit der „klassischen“ Art der Neuproduktentwicklung. Beinahe jeder Impuls, ob Ergebnis wissenschaftlicher Untersuchungen oder Erfahrung aus der Praxis, wird zur Innovationspraxis von vor X Jahren in Bezug gesetzt. Agile ist besser als die klassischen Methoden! Das ist die Botschaft. Ich würde diese Aussage unterschreiben, wenn klar wäre, was die klassischen Methoden sind. Wasserfall, V-Modell, Stage-Gate, Gantt-Planung, Projektmanager, etc. tauchen als Begriffe auf. Wie genau neue Produkte klassisch entwickelt wurden, welche Methoden und Spielregeln vorgegeben waren, und mit wie viel Disziplin diese angewendet wurden, findet nicht einmal in den wissenschaftlichen Studien Beachtung. Schade!
Ich denke, der Wettstreit agil (neu) vs. klassisch (alt) ist gar nicht notwendig. Das Einführen agiler Methoden und Haltungen kann die Innovationsperformance verbessern. Ob dies einfach nur daran liegt, dass Spielregeln wieder diszipliniert eingehalten, seit Jahrzehnten etablierte Methoden wie Kundeneinbindung und Prototypen-Tests wieder aufgefrischt oder neue Arbeitsweisen wie z.B. Retrospektiven nach jedem Sprint eingeführt werden, spielt im Grunde keine Rolle. Fakt ist: Die Innovationsfähigkeit fast aller Unternehmen steigt, wenn diese unter dem Titel „agiles Entwickeln“ ihr Innovationssystem überdenken und neu ausrichten.

• Agil ist super, aber nicht die heilsbringende Alles-Lösung
„Führe Scrum ein, ohne Kompromisse, ohne Hybrid, ohne Tal der Tränen – dafür mit Neuland Haftnotizen, das ist alles, was du für den Erfolg brauchst.“ Mit diesem nicht ganz ernst gemeinten Versprechen brachte ein Unternehmensberater die Lacher auf seine Seite. Fast allen Teilnehmern ist klar, dass die Welt nicht ganz so einfach ist.
Es wurde aber auch erzählt, dass mancherorts tatsächlich mit diesem Glauben Scrum eingeführt wird. Bestehende Systeme werden einfach mal abgeschafft. So sprach ein Vortragender davon, dass er die „Stage-Gates“ durch „System Days with Product Delivery“ ersetzt hat. Das Problem: es gibt keine Stage-Gates. Was er meinte, waren Gates. Und diese haben einen völlig anderen Zweck als die neu eingeführten System Days. Gates dienen primär dem Risikomanagement bei ungewissen Herausforderungen. System Days sollen für stakeholder-übergreifende Abstimmung des Produkts sorgen. Aus Unwissen wurde hier möglicherweise ein wichtiges Steuerungsinstrument der Scrum-Religion geopfert. Ich hatte den Eindruck, dass einige Akteure Begriffe wie Stage-Gate oder Wasserfall als Synonym für das alte, schlechte System nutzen, jedoch kaum etwas über diese Methoden wissen.
Dem überwiegenden Teil der Vortragenden und Teilnehmer war aber klar, dass agiles Entwickeln seine Stärken vor allem bei komplexen, noch unklaren Innovations-Herausforderungen ausspielen kann. Hierzu wurden das VUCA Modell wiederholt bemüht.

Als Erkenntnis bleibt: wir brauchen ein hybrides System, das je nach Herausforderungen eines Projekts den Einsatz der richtigen Methoden sicherstellt. Darüber hinaus muss ein projektübergreifendes Risiko- und Ressourcen-Management etabliert sein.

• Agil ist nicht gleich Scrum
Die meisten Unternehmen haben berichtet, dass sie sich mit Scrum auf den Weg zu einem agilen Unternehmen gemacht haben. Der Beitrag der Firma ASK Industries, und speziell jener von Frau Prof. Paetzold hat dazu aufgefordert, die Unterschiede der agilen Methoden genau zu beleuchten und zu überlegen, welche zu den Gegebenheiten und Herausforderungen des jeweiligen Unternehmens oder Projekts passen. So passt Scrum besonders gut, wenn wir erst während des Projekts viel über die Anforderungen an das neue Produkt lernen und es daher zu häufigen technischen Änderungen kommt. Kanban spielt seine Stärken aus, wenn wir bereits viel über die Bedürfnisse und Anforderungen wissen, es jedoch unzählige davon gibt. Design Thinking stellt den Innovationsaspekt neuer Produkte in den Mittelpunkt, während Xtreme Programming einen starken Qualitätsfokus hat.
Schließlich kommt die Sprache immer auch auf die Skalierbarkeit von agilen Methoden. Hierzu wurden Modelle wie SAFe, LeSS, Nexus, Scrum@ Scale oder Spotify Model ins Rennen geworfen. Bei der Auswahl der skalierenden Systeme gilt das gleiche: Genau drauf achten, welches am besten zur Situation und Herausforderung des Unternehmens passt.

• Wer darf / soll im agilen Reigen mitspielen?
Manche sehen die Anwendung agiler Methoden primär in der F&E-Abteilung bzw. in der „Entwicklungsphase“ eines Neuprodukt-Projekts. Die viel zitierte Interdisziplinarität bezieht sich dann meist auf unterschiedliche technische Disziplinen wie Mechanik, Elektronik und Software. Das Produktmanagement und manchmal Sales bekommen eine Rolle als Product Owner. Weitere Fachbereiche wie Einkauf, Qualität, Produktion laufen unter dem Begriff „Umfeld“. Spannend ist, dass in einer Studie der Hochschule Koblenz eben dieses Umfeld als eine der größten ungelösten Herausforderungen eines scrum-basierten Produktentwicklungssystems identifiziert wurde.
Das Unternehmen Erbe Elektromedizin scheint dieses Problem gelöst zu haben, indem sie für Produktinnovationen echte interdisziplinäre (Entwicklung, Produktmanagement, Fertigungsentwicklung, Einkauf, etc.) Projektteams mit 100% dedizierten Mitarbeitern bilden. Alle haben ihren Arbeitsplatz beim Team. Herausforderung der Fach-Mitarbeiter ist es, sich weiterhin mit ihrer Fachabteilung abzustimmen.
Die Rolle des Product Owners (PO) wirft auch immer wieder Fragen auf. In Scrum zeichnet dieser verantwortlich für das „WAS“, während das agile Team zuständig ist für das „WIE“. Dies sieht vor, dass der PO mit viel Überblick und guter Marktkenntnis die Eckpunkte eines neuen Produkts definiert, die konkrete Ausarbeitung aber dem verständigen agilen Team überlässt. Das Team soll die Vorgaben des PO „challengen“ und diese aufgrund von Erkenntnissen aus Iterationen mit Kunden bei Bedarf einer Änderung zuführen. Jedoch bestimmt nicht immer dieses Rollenverständnis die Innovationspraxis. Verkommt die Beziehung zwischen PO und Team zu einer Auftraggeber- vs. Abarbeiter-Rolle, besteht die Gefahr mit Scrum eine neue Ära des Silodenkens heraufzubeschwören (Lesen Sie dazu mehr unter diesem Link).

Fazit
• Auf der Methoden-Ebene besteht weitgehend Einigkeit, dass die agilen Werkzeuge die Projektarbeit positiv beeinflussen. Nicht alle Artefakte werden von allen gleich intensiv genutzt, hitzige Diskussionen werden darüber aber keine mehr geführt. Auf Methoden-Ebene hat die agile Hardware-Entwicklung einen guten Reifegrad erreicht.
• Auf der Organisations-Ebene herrscht deutlich mehr Diskussionsbedarf. Wie sieht das passende organisationale Umfeld für agiles Entwickeln aus? Brauchen wir 100% dedizierte Teams? Oder geht es auch anders? Wie funktioniert in einem agilen System Führung? Welche Rolle haben die bisherigen Linienführungskräfte? Gefühlt ist die Community hier gerade in der Findungsphase.
• Auf die Haltungs-Ebene (Mindset) wird zwar ab und an hingewiesen, eine fundierte Auseinandersetzung damit konnte ich jedoch nicht feststellen. Nach dem Motto „Haltung passiert schon, wenn wir genug am Umfeld schrauben“ wird mit diesem Thema noch recht unbedarft umgegangen. Möglicherweise werden wir uns auf der Agile PEP Minds 2022 verstärkt über Werte und Haltungen der Projektteams, POs und sonstigen Führungskräfte austauschen.
Sehr gut gefällt mir, dass eines der wichtigsten agilen Prinzipien sehr präsent ist, nämlich das Ausprobieren und laufende Verbessern. Björn Eberhard, der Konferenz-Vorsitzende, bezeichnet die Agile PEP Minds als jährliche Lern-Iteration für Anwender agiler Methoden. Diesem Anspruch wird die Veranstaltung gerecht. In diesem Sinne: weiter so!

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Innovationsprojekte beschleunigen? – Ja-Sager sind die größte Bremse

Klaus S. ist Gruppenleiter in der F&E eines mittelständischen Maschinenbauers. Er ist einer der Besten in seinem Fach. Dennoch ist sein Vorgesetzter mit ihm nicht zufrieden. Eine Kennzahl macht Sorgen: die Neuprodukt-Projekte, an denen Klaus beteiligt ist, haben eine durchschnittliche Time-to-Market von 48 Monaten. Aus einer Benchmarking-Studie weiß Klaus‘ Vorgesetzter, dass ein wichtiger Wettbewerber im Durchschnitt nur etwa 36 Monate für eine Neuproduktentwicklung braucht. Die Zielvereinbarung für Klaus ist somit schnell definiert: seine Projekte müssen schneller werden, um mindestens 25%.

Klaus sieht sich nun mit einer Reihe von Herausforderungen konfrontiert:

  • In seinen Augen arbeitet er bislang schon so gut und schnell wie möglich. Um deutlich schneller zu werden, müsste er die Qualität seiner Arbeit deutlich zurückschrauben. Aber das liegt gar nicht in seinem Naturell und wohl auch nicht im Interesse des Unternehmens.
  • Einige der Projekte erfordern neue technische Lösungen, für welche die eine oder andere Lernschleife notwendig sein wird. Da ist es schwierig einen Zeitplan zu erstellen, auf den man sich verlassen kann. Ob die Entwicklungszeit verkürzt werden kann, lässt sich im Vorhinein nicht sagen.
  • Grundsätzlich könnte er mehr Aufgaben an sein Team delegieren. Seine Teammitglieder sind jedoch alle noch ziemlich unerfahren, und Klaus hat ein besseres Gefühl, wenn er deren Projektarbeit überprüft. Das kostet Zeit.

Wir sind eingeladen, Klaus und seinen Vorgesetzten bei der Zielerreichung zu unterstützen. Zunächst sehen wir uns die Neuprodukt-Projektlandschaft an. Im Projektportfolio finden wir 62 aktive Projekte. In 4 davon ist Klaus Projektleiter und verantwortlicher Entwickler, in 4 weiteren arbeitet er als Projektteammitglied als verantwortlicher Entwickler mit. Er hat also in „seinen“ Projekten 12 Rollen zu erfüllen: 4 x Projektleitung, 8 x verantwortlicher Entwickler.

Die nächste Frage ist, wie viel seiner Arbeitszeit Klaus für die Projektarbeit überhaupt nutzen kann. Aktuell verwendet Klaus etwa

  • 8 Stunden pro Woche für Führungsaufgaben: Sein Team umfasst 10 Personen. Jeden Montagvormittag findet ein Team-Jour fix von 3 Stunden statt. Dazu kommen Einzelgespräche mit seinen Teammitgliedern zu deren Projekten.
  • 4 Stunden pro Woche für interne Kommunikation und Administration: Klaus hat seinerseits ein wöchentliches Treffen mit seinem Vorgesetzten (ca. 1 Stunde). Darüber hinaus erhält er regelmäßig Anfragen vom Produktmanagement, sowie aus der Produktion, in denen er um seine Erfahrung und Einschätzung gebeten wird.
  • etwa 2 Stunden pro Woche für das Studium von Fachliteratur und neuen Patenten.
  • 10 Tage im Jahr für den Besuch von Fachmessen und Symposien (inkl. Reisezeiten).

Bei einer 40-Stunden-Woche bleiben Klaus pro Woche etwa 24 Stunden Arbeitszeit für die Neuprodukt-Projekte. Dies entspricht etwa 2 Stunden pro Woche pro Rolle, die er in diesen Projekten einnimmt.

Sowohl Klaus als auch seinem Vorgesetzten wird schnell klar, dass Klaus in viel zu viele Projekte eingebunden ist. Und die Tendenz geht in die falsche Richtung: es werden laufend sehr interessante neue Ideen und Projekte eingebracht und auch gestartet.

Gemeinsam mit der Geschäftsleitung führen wir ein Gating-System sowie ein Innovations-Portfolio-Management ein:

  • Jedes Neuproduktprojekt durchläuft zu definierten Reifegraden (z.B. Business Case definiert, Entwicklung abgeschlossen) harte Gates. An diesen entscheidet ein Gatekeeper-Gremium, ob es für das Unternehmen eine gute Investition ist, weiter in dieses Projekt zu investieren.
    Zusätzlich wird am Gate geprüft, ob die notwendigen Ressourcen für die nächste Projektphase verfügbar sind. Ist dies nicht ausreichend gewährleistet, wird das Projekt „on hold“ gesetzt.
  • 4 Mal im Jahr analysiert und priorisiert der Führungskreis (Geschäftsleitung und Abteilungsleiter) das Portfolio der Neuprodukt-Projekte. Hierbei achtet dieser speziell auf folgende Aspekte: das Projekt-Portfolio
    • bildet die (Innovations-)Strategie des Unternehmens ab
    • maximiert den Wert des Neuprodukt-Portfolios
    • sorgt für eine gute Balance von Erfolgspotenzial und Risiken der Projekte
    • stellt sicher, dass nicht zu viele Projekte parallel laufen und Kapazitätsengpässe, Überlastungen und Verzögerungen vermieden werden.

Damit diese beiden Instrumente Wirkung zeigen, ist es notwendig, dass die Entscheider mit der richtigen Haltung ans Priorisieren und Ressourcen-Freigeben herangehen. Eine Führungskraft, die zu jeder Idee und jedem Projekt „JA“ sagt, bremst Neuproduktprojekte und überfordert seine Mitarbeiter.
Es steht außer Frage, dass das „Nein-Sagen“ zu Ideen bzw. laufenden Projekten eine herausfordernde Aufgabe ist. Selbstverständlich gibt es unterstützende Werkzeuge, wie z.B. eine Scorecard oder auch die Affektbilanz. Schlussendlich muss jeder Entscheider aber verinnerlicht haben, das nur ein fokussiertes Investieren in die richtigen Ideen und Projekte schnelles und erfolgreiches Entwickeln neuer Produkte ermöglicht.

In den folgenden eineinhalb Jahren wurde in Klaus‘ Unternehmen die Anzahl der aktiven Projekte auf 41 reduziert. Klaus hat aktuell noch 8 aktive Rollen in Projekten (Projektleitung und verantwortliche Entwicklung in 4 Projekten) – der Zielwert für Klaus liegt bei 5 aktiven Rollen.

Eine durchschnittliche Time-to-Market konnte für die Projekte von Klaus noch nicht ermittelt werden. Die beobachteten Projektphasen wurden im Vergleich zu ähnlichen Projekten deutlich beschleunigt.
In vergleichbaren Organisationen haben wir Verkürzungen der Time-to-Market von 30 bis 50 Prozent beobachtet.

Was es beim Aufbau eines Gating-Systems zu beachten gilt, und wie ein Best-Practice Innovations-Portfolio-Management aussieht, erfahren Sie direkt vom Best-Seller-Autor Prof. Robert G. Cooper im Seminar „Winning at New Products“ am

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Innovationsmanagement unter Spannung

Neue Publikationen zum Thema Innovationsmanagement schießen wie Pilze aus dem Boden. Durch die Flut an neuem oder manchmal auch nur scheinbar neuem Know How ergeben sich neue Gestaltungsmöglichkeiten aber vermehrt auch Spannungsfelder oder Schwierigkeiten, wofür man sich nun entscheiden soll. Während Entrepreneurship-Ansätze flexible und erfrischende Zugänge zu Innovationsvorhaben propagieren, scheinen klassische Ansätze mit strukturierten Prozessen ihre Gültigkeit nach wie vor zu behalten. Wie sollen Innovationsverantwortliche und Projektteams mit diesen widersprüchlichen Imperativen bezüglich State-of-the Art im Innovationsmanagement umgehen? Welche Orientierungen sollen in Innovationsprozessen gelten?

Die folgende Gegenüberstellung zeigt

  • beispielhafte Prinzipien klassischer Innovationsprozesse in traditioneller Management-Logik (links)
  • typische Haltungen aus Entrepreneurship-Ansätzen, wie z.B. Lean Startup, Effectuation oder Design Thinking (rechts).
einerseits … andererseits …
Mache es beim ersten Mal richtig Probiere Vieles und lerne aus Fehlern
Orientiere dich am Kundenfeedback und der Machbarkeit Gestalte die Zukunft visionär
Tue das Naheliegende und baue auf Bestehendem auf Suche nach unkonventionellen, radikalen Ideen / Lösungen
Agiere zielorientiert und nach Plan Agiere ergebnisoffen und flexibel
Orientiere dich am zu erreichenden Ziel Orientiere dich am maximal leistbaren Verlust
Schütze das Know-how, involviere ausgewählte Experten Sei offen und nutze alle Quellen für Inspiration und Austausch

 

Wir schlagen vor, das „entweder – oder“ zu überwinden und zu akzeptieren, dass wir uns in Innovationsprojekten innerhalb von Spannungsfeldern bewegen, deren Endpunkte niemals ausschließlich wahr oder falsch sind, sondern je nach Situation hilfreich oder hinderlich sein können.

Manchmal liegt der Schlüssel im „sowohl-als-auch“, z.B. nach dem Motto „Lass uns den Plan Schritt für Schritt flexibel anpassen!“

Andere Male scheint keine der beiden Optionen zu passen: Kundenfeedback lautet, „Bloß nichts ändern!“ Visionäre Ideen trauen wir uns daher nicht zu denken. Auf der Stelle Treten bringt uns auch nicht voran. Zum konstruktiven Umgang mit solchen Spannungsfeldern empfehlen wir, sich mutig auf sich selbst zu beziehen, das heißt: Wofür stehen wir als Unternehmen oder Marke? Wo wollen wir hin? Welche Chancen können wir nutzen? Wie würden wir mit Hindernissen und Rückschlägen umgehen? Aus den Antworten auf diese Fragen leiten Sie dann ein konkretes Vorgehen ab. Fehlt an dieser Stelle noch immer der Mut dazu, könnten Sie sich noch fragen: Was würde passieren, wenn wir nichts tun? Oder was, wenn wir genau das Gegenteil tun?

Wie Sie Innovationskultur in Ihrem Unternehmen so gestalten, dass jede „einerseits/andererseits“-Situation Ihren Innovationsprozess stärkt und Sie dabei unterstützt, die Ressourcen auf die richtigen Innovationsvorhaben zu fokussieren, erfahren Sie von Prof. Robert G. Cooper in seinem Seminar „Winning at New Products“ am 4. und 5. Oktober 2018 in Frankfurt. Informieren Sie sich dazu hier.

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Dann hat die Transition wohl nicht geklappt …

„Dann hat die Transition wohl nicht geklappt“ – diesen Satz hören wir in letzter Zeit ab und zu. Er kommt uns vor wie die Antwort eines Methoden-Evangelisten, wenn die Realität von der Lehre abweicht. Und dieser Evangelist hat Recht: die Methode scheitert an der Umsetzung. Die meisten modernen Ansätze wie Design Thinking, Scrum, Lean Start-up aber auch bereits etablierte wie Wasserfall, V-Modell oder Stage-Gate sind in sich absolut logisch. Perfekt umgesetzt sichert jede dieser Methoden ein effizientes und teilweise auch effektives Vorgehen. Eine perfekte Umsetzung sehen wir in der Realität jedoch selten, dadurch ausgelösten Frust bei Innovations­verantwortlichen dem entsprechend häufig.

 

Warum ist das Etablieren neuer Arbeitsweisen so schwierig?

Eines beobachten wir dazu immer wieder: Bei der Einführung neuer Methoden wird sehr viel Augenmerk auf die Prozesse, die Rollen und die Werkzeuge (Tools) gelegt und weit weniger auf die Menschen, die mit diesen Methoden arbeiten, insbesondere auf deren Haltungen und das daraus resultierende Verhalten.

These 1:    Manche Methoden überfordern die Informationsverarbeitungskapazität „normaler“ Menschen

Ein Beispiel dazu: Ein Beraterkollege hat unlängst seinen SCRUM-Ansatz für das Entwickeln neuer physischer Produkte damit angepriesen, dass dieser über 100 Einzelmethoden beinhaltet, die insgesamt eine hervorragende Anleitung zum transparenten und schnellen Entwickeln ergeben. Selbst wenn unter den 100 auch sehr einfache Methoden sind, wie der aus der Lean-Philosophie kommende „Go and See“ Ansatz (Beobachtung direkt am Ort des Geschehens), macht die bloße Zahl eine Implementierung schwierig und langwierig. Alle Einzelmethoden müssen erklärt, verstanden und eingeübt werden, damit sie in Kombi­nation ihre Wirkung entfalten können.

These 2:    Angesichts der Vielzahl neuer Spielregeln und Werkzeuge geht das Bewusstsein für den eigentlichen Zweck der Methode verloren.

Entwicklungsteams wie Entscheider sehen mitunter vor lauter Bäumen den Wald nicht mehr. Da kann es schon vorkommen, dass die ursprüngliche Absicht, nämlich die Entwicklung „dynamisch und flexibel“ zu gestalten, im Regel- und Werkzeug-Dschungel untergeht. Der Versuch alle methodischen Vorgaben zu erfüllen führt möglicherweise zu einem rigideren Vorgehen als zuvor und damit sich selbst ad Absurdum. Werden Rollendefinitionen unreflektiert übernommen, können sogar neue kontraproduktive Silos entstehen[1].

Ein weiteres Beispiel: Stage-Gate®-Prozesse, die mit fingerdicken Prozesshandbüchern und ellenlangen Checklisten hinterlegt sind. An Gate-Reviews prüfen die Entscheider die Umsetzung der Checklisten und die Einhaltung des Zeit- und Budgetplans. Vom ursprünglichen Zweck der Gates ist dann leider nicht mehr viel übrig. Gates sollen sicherstellen, dass die verfügbaren Ressourcen auf wenige, dafür aber die besten Projekte fokussiert werden (Trichterprinzip). Eine Vielzahl an Hilfsmitteln, Checklisten und Templates verführt dazu, sich mit der Kontrolle der korrekten und vollständigen Anwendung zu beschäftigen statt den Kerngedanken eines Stage-Gate®-Systems zu verfolgen und hauptsächlich der Frage nachzugehen „Ist dieses Projekt attraktiv genug, um weiter Zeit, Energie und Geld zu investieren?“.

 

Einfache mentale Modelle statt übertriebene „Toolifizierung“

Eines vorweg: Wir haben nichts gegen Werkzeuge. Ganz im Gegenteil: Werkzeuge helfen insbesondere, wenn sie

  • Analysen und Entscheidungen unterstützen,
  • Transparenz und effektive Zusammenarbeit fördern oder
  • Aufmerksamkeit auf das Wesentliche fokussieren und Zeit sparen.

„Toolifizierung“ wird dann zur Falle, wenn den Anwendern nicht klar ist, wozu die Tools eigentlich dienen sollen.

Die meisten Methoden basieren auf ein paar grundlegenden Prinzipien. Drei Beispiele aus dem Kontext Innovationsmanagement:

  • Das Stage-Gate-System ist aus der Erforschung von Erfolgsfaktoren für Neuprodukte hervorgegangen. Wendet man diese als Prinzipien an, steigert das die Erfolgswahrscheinlichkeit der Neuproduktentwicklung stark. Nummer 1 ist und bleibt wohl „Stifte mit deinem Angebot überlegenen Kundennutzen“. Weitere sind z.B. „Mach deine Hausaufgaben (Recherchen und Analysen) in der frühen Phase des Projekts, vor der Entwicklung“ oder „Stelle eine gut durchdachte und ausgeführte Markteinführung sicher“[2]
  • Lean Innovation liegt der Gedanke der Vermeidung von Verschwendung in der Innovationspraxis zugrunde. Je nach Lehre / Lehrstuhl wurde dieser Gedanke in 4 bis 12 Prinzipien formuliert, z.B. „Orientiere dich am Takt des Kunden“, oder „Strebe Perfektion an und verbessere die Prozesse kontinuierlich“.
  • Auch für das Agile Entwickeln wurde die Kernintention im Agilen Manifest mit 4 Leitsätzen und 12 Prinzipien formuliert, z.B. „Einfachheit: maximiere die Menge der nicht getanen Arbeit“, oder „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen“[3].

Unter Prinzip verstehen wir ein mentales Modell, das in einer Organisation anerkannt und in den Köpfen der Menschen verankert ist. Sind die Prinzipien einer Methode verinnerlicht, steigt die Wahrscheinlichkeit, dass die Beteiligten ihr Verhalten danach ausrichten – unabhängig vom Einsatz der einzelnen Werkzeuge (z.B. Checklisten, Standup-Meetings, etc.), die der Methode zugeschrieben werden.

 

Prinzipien einer modernen Neuproduktentwicklung

Viele Methoden teilen sich das eine oder andere Prinzip. So enthält fast jede zeitgemäße Innovations­methode das Prinzip der Nutzerintegration, der funktionsübergreifenden Zusammenarbeit und des iterativen Vorgehens. Es lohnt sich, das Innovationsmethodenrepertoire einer gründlichen Bestandsaufnahme zu unterziehen und zu hinterfragen:

  • Warum ist diese Methode für uns wichtig?
  • Was genau wollen wir mit deren Einsatz erreichen?
  • Wie würden grundlegende Prinzipien lauten, die wir daher leben sollten?

Daraus können sich einfache Grundsätze ergeben, wie z.B.

  • Wir holen uns früh, häufig und ernsthaft Feedback von Kunden und Anwendern
  • Wir legen die Priorität auf die Aktivitäten mit dem größten Beitrag zum Kundennutzen
  • Wir reflektieren regelmäßig unsere Arbeitsweise

Solche Gedanken haben sich auch Andere schon gemacht, etwa das Institut pd|z Product Development Group Zurich an der ETH Zürich: Dort wurde ein Set an „Principles“ für die Zusammenarbeit in Projektteams entwickelt. Dieses steht Studierenden als Unterstützung für Projektarbeit zur Verfügung. Diese Principles bilden einen schönen Querschnitt dessen, was zeitgemäßes Innovieren ausmacht[4], z.B.:

  • Iterate for Evolution – fail often to succeed sooner

Iterationen sind Lern-Zyklen, die es ermöglichen, schnell und effektiv Anforderungen und Rahmenbedingungen für Innovationen zu verstehen und das Angebot sukzessive zu verbessern. Voraussetzung dafür ist, dass Scheitern explizit erlaubt ist.

  • Breathe in Breathe out – alternate divergent and convergent activities

Das Entwickeln von Neuem ist eine Abfolge von sich mental Öffnen (z.B. für neue Ideen, alternative Lösungswege, etc.) und sich Fokussieren (z.B. Ideen selektieren, einen Lösungspfad auswählen und vorantreiben). Da diese beiden Phasen (divergent und convergent) einen unterschiedlichen Denk- und Arbeitsstil benötigen, sollte sich das Team immer bewusst sein, in welcher Phase es sich gerade befindet.

  • Create Energy – establish rituals and emotionalize your work

Die Team-Atmosphäre ist ein entscheidender Faktor für den Erfolg. Sich zu kennen, zu vertrauen und gegenseitig zu motivieren schafft eine Team-Energie, die für jedes Teammitglied einen positiven Geist erzeugt. Bewusst eingesetzte Rituale können das unterstützten. Sie aktivieren die Gefühlsebene und lenken die Emotionen der Beteiligten in gewollte Bahnen.

  • Get physical and test – build it to validate your thoughts

Die physische Umsetzung von Gedanken hilft, im Team ein gemeinsames Verständnis zu entwickeln, Ideen an potentielle Nutzer zu kommunizieren, gemeinsam zu analysieren und weiter zu denken.

  • Go where it hurts – prioritize and focus on the critical function

Die Aufgaben und Herausforderungen mit der größten Unsicherheit sind am schwersten anzupacken und zu lösen. Nichts desto trotz führt zum Erfolg kein Weg daran vorbei. Es ist also sinnvoll, sich möglichst früh damit zu beschäftigen.

  • Zoom out – understand your system and its context

Damit ist gemeint, von Zeit zu Zeit innezuhalten und den Blick von der Detailarbeit auf das große Ganze zu richten. „Zooming out“ hilft, Teilschritte im Zusammenhang zu sehen und zu prüfen, ob das Team nach wie vor in die gleiche Richtung unterwegs ist.

Wir finden solche Prinzipien nicht nur für Studierende nützlich. Die vollständige Sammlung findet sich hier: www.teamhives.net. Für den Zugang zum Principles Container muss auf der Plattform ein Team angelegt werden – und los geht’s.

Eine Studie mit 465 Studenten der ETH Zürich hat gezeigt, dass die Wichtigkeit der einzelnen Prinzipien je Projektphase variiert, aber durchaus auch team-spezifisch ist. Das bedeutet, dass sich ein Projektteam proaktiv mit den Prinzipien auseinandersetzen sollte und für die jeweiligen Herausforderungen im Projekt ein gemeinsames mentales Modell (eine Kombination aus Prinzipien) definiert.

 

Geteilte Prinzipien legen die Leitplanken fest

Wenn die Mitglieder einer Organisation zweckmäßige Prinzipien verinnerlicht haben und entsprechend über geteilte mentale Modelle bezüglich Erfolgsgrundlagen und Arbeitsweisen verfügen, legt das Leitplanken fest. Es muss meist nicht mehr viel diskutiert werden, wie Dinge anzugehen sind. Vieles geschieht „automatisch“, wie es geschehen soll. Man spart Planungsaufwand, Entscheidungsenergie und Abstimmungszeit.

Das Finden und Verinnerlichen der für die Organisation passenden und hilfreichen Prinzipien ist ein laufender Veränderungsprozess, der nicht von heute auf morgen einfach einzuführen ist. Lebt eine Organisation eine Kultur der Prinzipien, geben neue Methoden bzw. deren zugrundeliegende Prinzipien einen Impuls, die etablierten mentalen Modelle zu hinterfragen und weiterzuentwickeln, wo es nützlich ist. Das Integrieren neuer Prinzipien in eine bestehende Prinzipien-Landschaft ist erfolgversprechender als eine radikale Umstellung auf eine neue Methode mit all ihren Denkweisen, Verhaltensmustern, Werkzeugen und Rollen. Die Transition klappt dann besser und schneller.

 

[1] Näheres dazu im Blogbeitrag http://www.five-is.com/ist-agile-development-das-neue-silodenken

[2] Cooper, R.G., 2017. Winning at New Products – Creating Value Through Innovation,5th edition, Seite 39ff

[3] http://agilemanifesto.org/iso/de/principles.html

[4]    www.teamhives.com
Hächler, I., Mussgnug, M., Boës, S, Meboldt, M., 2016. Coaching Students with Principles.
Weibel, B., Mussgnug, M., Boës, S, Meboldt, M. 2015. Team Principles and Product Development.

  1. 6. Juni

    It’s all about the necessary mindset. Sehr interessanter Beitrag, vielen Dank!

    gepostet von Name* um 17:57 Uhr

* Pflichtfelder bitte unbedingt ausfüllen

Ist Agile Development das neue Silodenken?

Viele Unternehmen haben begonnen, agile Methodik in der Neuprodukt-Entwicklung intensiv zu testen und breit zu implementieren. Mit großem Interesse verfolgen wir die kommunizierten Erkenntnisse und Diskussionen. Dabei beschleicht uns der Verdacht, dass die eine oder andere Umsetzung agilen Entwickelns ein Rückschritt in „altes“ Silodenken ist. Kann das denn sein?

Wir beziehen uns hier auf Berichte vornehmlich großer deutscher Unternehmen. Die eingesetzte Methodik baut meist auf SCRUM bzw. skalierenden Modellen wie LeSS, Scrum of Scrum oder SaFE auf.
Typische Spielregeln dieser Modelle sind:

  • Der Product Owner (PO, in manchen Fällen auch ein Product Owner Team) definiert das Backlog für die Produktentwicklung. Der PO entscheidet, woran das bzw. die Entwicklungs-Teams in den Sprints arbeiten.
  • Die agilen Entwicklungs-Teams sind meist interdisziplinäre Entwickler-Teams, sprich Teams mit Mitgliedern unterschiedlicher technischer Expertise (z.B. Mechanik, Elektronik, Software). Idealerweise gibt es keine Hierarchie innerhalb dieser Teams, um eine gute Voraussetzung für Selbstorganisation und Selbstverantwortung zu schaffen.
  • Das Projekt ist in gleichmäßige Sprints getaktet. Die Entwicklungs-Teams agieren alle im gleichen Takt und nutzen die gleichen Werkzeuge (wie z.B. Kanban oder Standup Meetings).
  • Die eingesetzten Methoden sehen eine kundenzentrierte Produktentwicklung vor, also eine Entwicklung, in welcher der Nutzen der Anwender im Fokus steht. Hierzu werden im Zuge eines Projekts mehrere Iterationen zum Kunden geplant (z.B. in jedem 5. Sprint).
  • Agile Coaches unterstützen Product Owner und Linienmanager und begleiten die Entwicklungs-Teams bei der Einführung und Durchführung der neuen Vorgehensweise.

Die Agile Coaches berichten von zwei wesentlichen, positiven Veränderungen durch die neue Vorgehensweise:

  1. Die Transparenz in den Projekten nimmt deutlich zu. Es besteht eine sehr gute Übersicht, welche Teams und Personen an welchen Arbeitspaketen und Baugruppen gerade arbeiten und bis wann diese erledigt sein sollen. Dies ermöglicht eine bessere Koordination der Entwicklungsteams und auch der unterschiedlichen technischen Disziplinen untereinander.
  2. Die Teams erhalten im Rahmen der Sprints größere Entfaltungsspielräume. Durch regelmäßige Retrospektiven steigt die Qualität der Zusammenarbeit des Teams kontinuierlich an. Dies ermöglicht eine hohe Dynamik im Team und äußert sich in hoher Motivation der Teammitglieder.

Die geschilderten Spielregeln klingen einleuchtend, die berichteten positiven Effekte sind bereits durch Studien nachgewiesen. Wo orten wir also das Silodenken?

Aus der Innovationsmanagement-Forschung (u.a. durch Professor Robert G. Cooper) wissen wir, dass interdisziplinäre Projektteams zu den wichtigsten Erfolgsfaktoren für erfolgreiche Neuproduktentwicklung gehören. Gemeint ist damit die enge Zusammenarbeit von mindestens Produktmanagement/Marketing, Entwicklung und Produktion (ggf. zusätzlich noch Vertrieb, Supply Chain, Prozesstechnologie, Qualität, etc.).

Dieses Team aus Experten der wichtigsten Disziplinen ist gemeinsam für die erfolgreiche Entwicklung und Markteinführung der neuen Leistung verantwortlich – jedes einzelne Teammitglied für das gesamte Projekt und nicht nur für seinen Beitrag.
Ein entsprechendes Teamverständnis ist auch eine der wichtigsten Voraussetzungen für hohe Geschwindigkeit in Produktinnovationsprojekten.

In SCRUM bekommt das Produktmanagement die Rolle des Product Owners. Zunächst liegt es in seiner Verantwortung, ein Product Backlog aufzubauen. Hierzu ist dieser (hoffentlich) in direktem Kontakt mit Kunden bzw. Nutzern, um deren Bedürfnisse und Probleme möglichst im Detail zu verstehen und ein attraktives Werteversprechen zu definieren.
In der Folge vertritt der PO den Kunden gegenüber dem Entwicklungsteam. Er spricht „für den Kunden“, priorisiert die Kundennutzen und Features und diktiert somit die Projektinhalte. Dadurch wird Produktmanagement zum „Auftraggeber“ für das Entwicklungsteam und steht gefühlt über den Entwicklern.

Die Verantwortung eines Produktmanagers in der Rolle eines PO ist deutlich höher als in einem Entwicklungsteam, in dem alle Kernteam-Mitglieder für das Gesamtprojekt verantwortlich sind. Neben der Verantwortung steigen in SCRUM aber auch die negativen Folgen einer Fehleinschätzung durch die einzelne Person des Produktmanager.

Die Mitglieder des Entwicklungsteams in SCRUM haben meist nur direkten Kontakt mit dem „internen Kunden bzw. Stakeholder“. Somit sind alle Informationen und Vorgaben im Product Backlog bereits mindestens durch einen Wahrnehmungsfilter (nämlich den des Product Owners, im schlimmsten Fall durch weitere Filter der Key Accounts / Vertriebsmitarbeiter) gegangen. Es geht für die Entwickler die Möglichkeit verloren, die Anwendung und die vom Kunden kommunizierten Bedürfnisse und Probleme aus erster Hand zu verstehen und aus der Entwickler-Perspektive zu interpretieren. Ein fehlendes oder falsches Verständnis bei den Entwicklern führt aber möglicherweise zur Auswahl der falschen technischen Lösung …

Auch scheinen Fertigungstechniker, Produktions- und Supply Chain Mitarbeiter, etc. keinen „Stammplatz“ in den Entwicklungsteams zu haben. Diese werden gegen Ende des Entwicklungsprojekts eingebunden, und schließlich wird das Projekt dann an „Operations“ übergeben.

Wenn wir den Blick von den vielen hilfreichen und absolut sinnvollen Methoden aus SCRUM auf den übergeordneten Projektaufbau richten, stellen wir fest, dass dieser der Entwicklungspraxis der 80er Jahren gleicht: Produktmanagement schreibt ein Lastenheft (Backlog?), die Entwicklung erarbeitet ein Pflichtenheft und entwickelt einen Prototypen (Ergebnis der Entwicklungs-Teams), die Fertigungstechnik überführt es in die Produktion, welche dann die Fähigkeiten auf eine Serienproduktion hochskaliert, schließlich landet das Produkt beim Vertrieb und nach viel Geduld beim Kunden. Jede Projektphase wird von einer anderen Disziplin beherrscht und verantwortet – Silo für Silo. Diese Art der Projektabwicklung galt mit dem Aufkommen von Stage-Gate® Ende der 80er Jahre als langsam und veraltet.

Damit wollen wir keineswegs behaupten, dass agiles Entwickeln veraltet ist. Wir denken jedoch, dass der Fokus weniger auf den Werkzeugen und Methoden der Entwicklungs-Teams liegen sollte, als vielmehr auf der Frage, wie echte Interdisziplinarität mit gemeinsam getragener Verantwortung sichergestellt werden kann.

In einigen Unternehmen wird diese „echte“ Interdisziplinarität in einem Product Owner Team sichergestellt. Dieses erfüllt dann die Funktion des verantwortlichen Projektteams für das Neuproduktprojekt – von der Idee bis zur erfolgreichen Markteinführung, wie von Prof. Cooper beschrieben. Dieses Product Owner Team vergibt dann Entwicklungsaufgaben an Entwicklungs-Teams und steuert diese mit Hilfe des Product Backlog.
Dies wiederum bedeutet, dass der größere Hebel zur schnellen und erfolgreichen Umsetzung eines Neuproduktprojekts in Gestaltung, Arbeitsweise und Methoden des PO Teams liegt.
Die aktuelle Diskussion der agilen Methodik liegt aber nach wie vor beinahe ausschließlich bei den Entwicklungsteams.

Wenn Sie mehr über die Erkenntnisse und Erfahrungen von agilen Methoden in einem ganzheitlichen Innovationssystem erfahren wollen, können wir das Buch „Winning at New Products – 5th edition“ empfehlen. Oder Sie lassen sich die Inhalte des Buches vom Autor Prof. Robert G. Cooper persönlich erläutern und besuchen das Seminar zum Buch nahe Frankfurt am 23. Und 24. April 2018. Weitere Informationen zum Seminar finden Sie hier.

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Beyond Stage-Gate: Echte Innovationen in Rekordzeit

Im Herbst 2017 hat Professor Dr. Robert G. Cooper die 5. Auflage seines Bestsellers „Winning at New Products“ veröffentlicht. Er stellt darin eine neue Generation des Stage-Gate® Systems vor. Aus diesem Anlass reflektieren wir die Stage-Gate-Praxis im deutschsprachigen Raum und werfen einen Blick auf die Neuerungen der 5. Generation, die Cooper unter der Überschrift „Beyond Stage-Gate“ einführt.

Wer heute noch ein Stage-Gate-System der 2. Generation verwendet, ist in den 1990ern stehen geblieben und nimmt damit bedeutende Nachteile in Kauf in Bezug auf

  • Erfolgsquote von Innovationsprojekten,
  • Time-to-Market neuer Produkte und
  • Motivation der Projektteams.

Seit den 1980ern wurde das Stage-Gate System in führenden Unternehmen weltweit kontinuierlich weiterentwickelt. Bob Cooper analysierte ständig die aktuellen Praktiken der erfolgreichsten Innovations­systeme und hat diese in der jeweils neuesten Version seines Bestsellers beschrieben: Die 2. Generation (1993) integrierte die Ergebnisse der damals aktuellen Erfolgsfaktorenforschung (z.B. interdisziplinäre Teams, profunde Hausaufgaben vor der Entwicklung, etc.). In der 3. Generation (2000) stand das Beschleunigen von Neuproduktprojekten im Fokus. Die 4. Generation (2011) brachte dann Spiral Development (regelmäßige Kundenfeedbackschleifen), Lean und Open Innovation in die Stage-Gate Systeme. Die 5. Generation „Beyond Stage-Gate“ adressiert die Herausforderung „Bold Innovation in Record Time“.

Wie aktuell ist das Stage-Gate System in Ihrem Unternehmen?

Dies können Sie feststellen, indem Sie prüfen, ob Ihr Innovationssystem systematisch und durchgängig folgende Praktiken sicherstellt:

  1. Überzeugender Kundennutzen und Mehrwert für Käufer / Nutzer stehen im gesamten Innovationsprozess im Fokus aller Beteiligten. In allen Phasen setzen wir Aktivitäten, um Anwendung und Anwendungsumfeld sowie Kundenbedürfnisse vertieft zu verstehen.
  2. Bei unseren Innovationsprojekten ist ein interdisziplinäres Projektteam durchgehend für die Ergebnisse verantwortlich: von der Konzeptphase über die Entwicklung bis zur erfolgreich eingeführten neuen Marktleistung.
  3. Wir fokussieren unsere Ressourcen auf die attraktiven Projekte. Das bedeutet, dass wir an Gates Projekte stoppen, auch wenn es weh tut.

Wenn diese 3 Aussagen auf die Innovationspraxis Ihres Unternehmens zutreffen, lautet die Diagnose: alt aber gut! Ihre Organisation lebt wohl einen Stage-Gate-Prozess der Generation 2 oder 3. Sich mit den Weiterentwicklungen zu beschäftigen wird sich lohnen. Lesen Sie also hier weiter.

Falls a), b) oder c) in Ihrem Unternehmen nicht zum Standard gehört, kann es mehr bringen, zunächst die Grundpfeiler des Stage-Gate Systems zu renovieren bevor Sie sich in Richtung Beyond Stage-Gate bewegen.

Was ist neu – Beyond Stage-Gate?

Auf den ersten Blick ähnelt Beyond Stage-Gate dem traditionellen Stage-Gate (Generation 2 bis 4). Es gibt Stages, in denen die Projektarbeit verrichtet wird und Gates, an denen Go-Stopp Entscheidungen über das Projekt gefällt werden. Auf den zweiten Blick stechen drei wesentliche Weiterentwicklungen ins Auge:

1.  Beyond Stage-Gate ist adaptiv und schnell

Klassische Produktentwicklung kennt ein Lasten- und Pflichtenheft. Zunächst definiert ein interdisziplinäres Team (hoffentlich!), welche Anforderungen das neue Produkt erfüllen und wie es grundsätzlich positioniert werden soll. Je enger dieses Team dabei mit potentiellen Zielkunden interagiert, desto besser. Diese Anforderungen werden dann in technische Spezifikationen übersetzt, die es in der Entwicklungsphase umzusetzen gilt. Dieses Vorgehen hat nachweislich zu tollen Erfolgen geführt.

Seit ein paar Jahren ändern sich jedoch die Rahmenbedingungen für Neuprodukt-Projekte:

  • Im Umfeld von Digitalisierung, Internet of Things, Künstlicher Intelligenz, etc. wissen Kunden immer weniger, was sie eigentlich brauchen.
  • Trends, Bedürfnisse und Wettbewerbsangebote verändern sich immer schneller. Mitunter ändern sich die Rahmenbedingungen für ein Projekt mehrmals während eines Entwicklungszyklus.

Dadurch ist es beinahe unmöglich geworden, ein vollständiges, längerfristig gültiges Lastenheft zu definieren und „einzufrieren“. Hält eine Organisation an diesem Vorgehen fest, steigt der Anteil der wenig erfolgreichen Projekte bzw. die Projektlaufzeiten verlängern sich mitunter massiv, weil es mehrfach heißt „zurück zum Start“.

In einem Stage-Gate Systeme der neuesten Generation passen die Projektteams das Vorgehen dem jeweiligen Projektkontext an. Drei Praktiken haben Top-Innovatoren dazu etabliert:

  • Spiral Development: Über iterative Lernschleifen nähert sich das Projektteam gemeinsam mit potenziellen Zielkunden dem finalen neuen Produkt an. Diese Iterationen finden in allen Projektphasen statt. Das kann bedeuten, dass das zu entwickelnde Produkt zu Beginn der Entwicklungsphase noch zu weniger als 50% definiert ist.
  • Kontextbasierte Stages und Gates: Kein Projekt ist genau wie das andere. Diesem Umstand muss der Prozess gerecht werden. In einem Beyond Stage-Gate System wird daher die Anzahl der Stages und Gates dem Risiko bzw. der Komplexität des Projekts angepasst. Je höher das Risiko / die Komplexität desto mehr Gates im Sinn von Qualitäts und Ressourcen-Kontrollpunkten sollte das Projekt durchlaufen. Zunehmend haben Unternehmen mehrere Stage-Gate-Prozesse für unterschiedliche Projekttypen installiert, z.B. für „echte“ Innovationen, für Modifikationen bestehender Produkte, für Technologie- und Plattformentwicklungen. Neben der Anzahl der Stages und Gates werden auch die Kriterien zur Bewertung der Attraktivität der Projekte an den jeweiligen Typ angepasst. Während bei Produktmodifikationen eine frühe finanzielle Bewertung gut machbar ist und sich für die Priorisierung der Projekte gut eignet, ist das Heranziehen der gleichen Kriterien für Innovationen mit hohem Neuheitsgrad oder auch für Plattformentwicklungen nicht ungefährlich. Bei solchen Vorhaben stehen in den frühen Projektphasen noch keine belastbaren Zahlen zur Verfügung. Erste Schätzungen liegen mitunter um Potenzen daneben. Stage-Gate-Systeme mit Fokus auf finanzielle Kriterien „produzieren“ Projektportfolios mit vielen Low-hanging Fruits und wenigen wirklich zukunftssichernden Entwicklungen. Die besten Innovatoren vertrauen bei dieser Art von Projekten auf Kriterien, welche die Erfolgskriterien innovativer Produkte abprüfen, z.B. Kundennutzen, Überlegenheit gegenüber Wettbewerbslösungen, Marktattraktivität, Machbarkeit, etc.
  • Risk-based Contingency Model: Innerhalb der Stages ist die Zeit des „sklavischen“ Abarbeitens von Checklisten endgültig vorbei. Das Projektteam identifiziert jene Aktivitäten, welche das Projekt am effizientesten voranbringen und Ungewissheit bzw. Risiken rasch reduzieren. Dieses Vorgehen wird dann am Gate mit den Gatekeepern vereinbart. Die Deliverables für das darauf folgende Gate werden entsprechend festgelegt. Cooper empfiehlt dazu – insbesondere zu Beginn des Projekts – das „Innovation Project Canvas“ als Werkzeug. Unternehmen, die es einsetzen, berichten von einer Verkürzung der frühen Projektphase um 1 bis 2 Monate bei gleicher oder sogar höherer Qualität der Ergebnisse.

2.  Agiles Entwickeln im Stage-Gate System

Der Begriff agil ist seit etwa 4 Jahren aus den Programmen der Innovationskonferenzen nicht mehr wegzudenken. Aus der Software-Entwicklung kommend haben in den letzten Jahren agile Methoden und Denkweisen die Entwicklung von physischen Produkten massiv geprägt.

Auch wenn der eine oder andere agile „Evangelist“ in Agil den alleinigen Heilsbringer für alle Probleme in der Entwicklung sieht, setzen führende Unternehmen wie Honeywell, LEGO, Danfoss, Corning oder Tetra Pak auf hybride Agile-Stage-Gate-Systeme.

  • Das Stage-Gate System bildet hierbei den Rahmen für alle Neuprodukt-Aktivitäten der Organisation und stellt sicher, dass die richtigen Projekte effizient und schnell zum Erfolg geführt werden.
  • Agile Methoden setzen hingegen primär an der Projektmanagement-Ebene an und verbessern die Motivation der Projektteams sowie die Transparenz und Lernfähigkeit in den Projekten. *

Ein hybrides Agiles Stage-Gate-System sieht also die Nutzung von agilem Projektmanagement innerhalb der Stages vor, während die Gates dieselbe Funktion wie im klassischen Stage-Gate-Prozess erfüllen.

*Agile Methoden werden vielfach mit dem Versprechen auf verkürzte Produktentwicklung, bessere Termintreue, reduzierte Entwicklungskosten oder erhöhte Produktivität des Entwicklungsprojekts eingeführt. Die Universität der Bundeswehr München hat auf der Agile PEP Minds 2017 eine Studie (Agile Entwicklung physischer Produkte – Überzogene Erwartung oder tatsächliches Allheilmittel?) vorgestellt, die entsprechende Erwartungen / Versprechungen relativiert.

Was kennzeichnet agiles Entwickeln?

  • Eine komplexe Herausforderung wird in kleine, im Rahmen von 1 bis 4 Wochen zu lösende Teilaspekte unterteilt. Diese werden hinsichtlich Nutzenbeitrag für den Kunden priorisiert und in getakteten Sprints umgesetzt. Ziel ist dabei, in jedem Sprint ein möglichst fertiges und für den Kunden bereits nutzbares Ergebnis zu erzielen. Eine Vielzahl an Spielregeln, Methoden und Werkzeugen (z.B. kurze tägliche Abstimmungsmeetings, Lernschleifen nach jedem Sprint) stellt sicher, dass innerhalb und außerhalb des Projektteams jederzeit sichtbar ist, wer gerade an welchem Puzzleteil des Projekts arbeitet.
  • Agil ist nicht nur als Methodenset zu verstehen, sondern als spezielles Mindset. Das agile Projektteam agiert weitgehend selbstorganisiert und verantwortet die Ergebnisse jedes Sprints. In vielen Projektteams löst dies eine hohe Dynamik und Motivation aus.
  • Ein wichtiger Aspekt des agilen Selbstverständnisses ist mit der Aussage „Experimentieren statt Diskutieren“ gut beschrieben. Bevor ein Thema, ein Lösungsansatz oder ein Nutzen „zerredet“ wird, überlegt sich das Team, wie es dazu möglichst praktische Erfahrungen machen kann. Idealerweise wird dabei dann auch direkt der Kunde eingebunden.

Klassisches wie agiles Projektmanagement haben Stärken und Schwächen. Der größte Unterschied liegt wohl im Umgang mit Planung und Unvorhergesehenem. Im klassischen Projektmanagement wird versucht, einen möglichst realistischen Plan bis zur Zielerreichung (z.B. Abschluss eines Stages) zu erstellen und einzuhalten. Unvorhergesehene Ereignisse und Ergebnisse werden als Störung empfunden bzw. erfordern gekonntes Risiko- und Ressourcenmanagement. Im agilen Projektmanagement wird zwar auch ein grober Gesamtprojektplan erstellt, der Fokus liegt aber wesentlich stärker auf dem in den nächsten 1 bis 3 Sprints Erreichbaren. Neue Erkenntnisse oder auch veränderte Prioritäten der Aktivitäten werden von Sprint zu Sprint berücksichtigt, ohne jedes Mal das Projekt neu planen zu müssen. Dieser Aspekt qualifiziert agiles Projektmanagement insbesondere für Projekte in einem ungewissen und komplexen Umfeld – sprich: Projekte in den frühen Projektphasen und/oder mit hohem Innovationsgrad.

Die Firma Corning setzt agiles Projektmanagement beispielsweise vornehmlich bei den Projekten mit hohem Risiko ein (maximal 20% der Projekte). Für einfache, gut vorhersehbare Produktmodifikationen scheint klassisches Projektmanagement effizienter zu sein.

3.  Stage-Gate als ganzheitliches System

Stage-Gate war ursprünglich als Anleitung für erfolgreiche Projektumsetzung von der Idee bis zum fertigen Produkt am Markt konzipiert. Im Zuge der Evolution über 3 Jahrzehnte ist daraus ein ganzheitliches Innovationssystem geworden. Dieses umfasst methodische Ansätze zur Innovationssteuerung, die weit über Stage-Gate-Prozesse für verschiedene Projektarten hinausgehen. Dazu gehören z.B. Ansätze für die Definition von Innovationszielen und Suchfeldern, für das Projekt-Portfolio-Management, das Ideenmanagement, und das Innovationscontrolling. Diese sind eng verzahnt mit Aspekten der Führung und Organisationskultur.

Beispielsweise vereinbart im Gatemeeting das Projektteam mit den Gatekeepern, dass das Team die geforderten Ressourcen bekommt, um im nächsten Stage ein Projekt bis zu einem gewissen Reifegrad in hoher Qualität und Effizienz selbstverantwortlich weiterzuentwickeln. Die Freiheitsgrade des Projektteams während des Stages sind hoch, die Einmischung der Führungskräfte gering. Beim nächsten Gate prüfen die Gatekeeper die Qualität und Belastbarkeit der Ergebnisse des vorangegangenen Stages und bewerten die Attraktivität des Projekts für das Unternehmen. Diese im Gate validierten Informationen (z.B. Kennzahlen zur wirtschaftlichen Attraktivität, Ressourcenbedarfe) stehen dann für strategische Priorisierungsentscheidungen im Projekt-Portfolio-Management zur Verfügung. Ressourcenengpässe können frühzeitig erkannt und entsprechende Maßnahmen ergriffen werden.

Damit die Entscheider über das Projekt-Portfolio vor lauter Projekte- und Ressourcenjonglieren nicht die übergeordnete Strategie aus den Augen verlieren, wird diese in strategische Ressourcentöpfe (Strategic Buckets) übersetzt und dient im Portfolio-Prozess als Leitplanke für Priorisierungsentscheidungen. Identifiziert das Entscheiderteam Lücken in einem oder mehreren Strategic Buckets, initiiert es eine Ideenkampagne zur Generierung neuer Ideen für dieses Strategiefeld.

Werden nun Änderungen im Stage-Gate-System vorgenommen, z.B. agiles Projektmanagement wird für radikale Innovationsprojekte eingeführt, ist es wichtig, die Auswirkungen auf das gesamte System zu berücksichtigen und die Neuerung in geeigneter Weise in die Prozesslandschaft entsprechend einzubetten.

Das Schmiermittel eines Beyond-Stage-Gate-Systems ist ein innovationsförderndes Klima, das geprägt ist von gelebtem Intrapreneurship, lern- und chancenorientierter Zusammenarbeit und einem ebensolchen Umgang mit Fehlern oder Scheitern. Dieses zu gestalten bzw. sich entfalten zu lassen muss Teil jeder Innovationsmanagement-Verantwortung sein.

Was bedeutet das für Ihr Unternehmen?

Wenn Sie meinen, dem Innovationssystem Ihres Unternehmens könnte ein Update gut tun, empfehlen wir zunächst, „Beyond Stage-Gate“ im Detail zu verstehen. Dazu eignet sich das neue Buch Winning at New Products“ vorzüglich. Alternativ bietet sich das Seminar zum Buch an, das am 23./24. April 2018 im Raum Frankfurt stattfindet. Dort haben Sie die Möglichkeit von Professor Cooper selbst zu erfahren, wie Beyond Stage-Gate im Detail funktioniert. Dieses Seminar eignet sich übrigens auch ausgezeichnet, Führungskräfte für die Neuproduktentwicklung und für die Entwicklung des Innovationssystems im Unternehmen (wieder) zu begeistern.

Wenn Sie dann die Innovationspraxis im eigenen Unternehmen neu- oder umgestalten, renovieren Sie bei Bedarf zunächst die Grundpfeiler Ihres Stage-Gate-Systems: starke Markt- und Kundenorientierung im gesamten Prozess, echtes Teamwork in funktionsübergreifenden Teams, klare und verbindliche Ressourcenentscheidungen („Gates with Teeth“), und nicht zuletzt das Trichterprinzip, das bedeutet in viele Ideen ein wenig investieren, um in wenige gute Projekte viel zu investieren. Das heisst auch, zu vielen Themen „nein“ zu sagen.

Die Firma Danfoss hat beispielsweise zunächst ihren bestehenden Prozess optimiert und schlanker gestaltet. Der Prozessverantwortliche berichtet, dass Projekte durch diese Maßnahme um bis zu 50% beschleunigt wurden. Erst in einem zweiten Schritt wurde Beyond Stage-Gate eingeführt, was noch einmal zu einer Verkürzung der Projektdurchlaufzeit von ca. 30% geführt hat.

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Leadership und Innovation: Sind Sie bereit für den Paradigmenwechsel?

Welchen Beitrag zum Erfolg Ihrer Innovationsaktivitäten leisten Sie als Führungskraft?

Evaluieren Sie Innovationsprojekte und fokussieren Sie die Ressourcen auf wenige Projekte? Überprüfen Sie regelmäßig, ob die Projektteams auf dem richtigen Weg sind? Schützen Sie Ihre Mitarbeiter vor Querschüssen und störenden Ablenkungen aus der Organisation?

Möglicherweise fällt es auch in Ihre Verantwortlichkeit, das Innovationssystem Ihres Unternehmens up-to-date zu halten. In diesem Fall haben Sie sicher mitverfolgt, dass es in den letzten Jahren im Innovationsmanagement wesentliche Neuerungen gegeben hat: Agile Development, Design Thinking, Effectuation, Corporate Startup sind nur einige der Schlagworte.

Was zunächst wie eine einfach anzuwendende Methodik (z.B. Design Thinking) aussieht, entpuppt sich bei näherem Hinsehen und Ausprobieren als Revolution der bisherigen Innovationspraxis. Im geschützten Umfeld eines Pilotprojekts erzielt die neue Methode möglicherweise vielversprechende Ergebnisse. Beim Ausrollen auf die gesamte Organisation stellen die Verantwortlichen dann fest, dass sich angefangen vom Vokabular, über Abläufe, Verantwortlichkeiten, interne Kommunikationswege, Rollenverständnisse bis zur gelebten Kultur einiges mehr ändern muss.

Auch oder insbesondere die Rolle der Führungskräfte ändert sich mit den neuen Ansätzen im Innovationsmanagement! Nicht zuletzt deshalb, weil sich die Rolle der Projekt-Umsetzer ändert. Mehr als je zuvor wird von den Kern-Projektteams unternehmerisches Denken und Handeln, Begeisterung und Herzblut für das Projekt und die Übernahme von Verantwortung gefordert. Einige Ansätze fordern gar den Aufbau temporärer Organisationseinheiten, die eigenverantwortlich über einen längeren Zeitraum Produktprogramme erfolgreich betreiben.

Vom Projektmitarbeiter zum Intrapreneur

Ein Kern-Projektteam besteht aus 3-5 Personen aus unterschiedlichen, für die erfolgreiche Umsetzung notwendigen Disziplinen. Dieses Kern-Projektteam ist für die Projektumsetzung verantwortlich. Dies bedeutet, dass jedes einzelne Teammitglied die Verantwortung für den Erfolg des gesamten Projekts trägt, also auch für jene Aspekte, die nicht im jeweiligen Fachbereich liegen. Dadurch setzt sich beispielsweise der Entwickler intensiv mit der Positionierung eines neuen Produkts am Markt auseinander und steht hinter dieser. Umgekehrt interessiert sich auch der Produktmanager für die technischen Aspekte des Projekts.

Vom Kern-Projektteam wird erwartet, ein Projekt im Sinne des Unternehmens umzusetzen. Dies beinhaltet auch, den Wertbeitrag des Projekts für das Unternehmen zu kennen, es in Hinblick auf Qualität, Ressourcen und Zeit zu optimieren und das Projekt auch nach außen hin entsprechend zu vertreten. Beinahe alle modernen Innovationsansätze empfehlen intensive, frühe und fortlaufende Interaktion mit der Zielgruppe. Neben der Bedürfnisforschung werden Lösungskonzepte, dysfunktionale Mock-ups, Funktionsmodelle, Prototypen, etc. mit dem Kunden geteilt, um frühes, möglichst konkretes Feedback zu erhalten. Berechtigterweise führen Führungskräfte hierzu Bedenken auf, wie z.B.

  • Beim Kunden werden Erwartungen geweckt, die ggf. später nicht gehalten werden können (z.B. wenn ein Projekt abgebrochen wird).
  • Die Wahrscheinlichkeit steigt, dass der Wettbewerb von den Projekten und deren Inhalte Kenntnis erlangt und entsprechend früher darauf reagieren kann.
  • Die patentrechtliche Schützbarkeit kann durch so ein Vorgehen massiv gestört, wenn nicht sogar zunichte gemacht werden.

Von den verantwortlichen Projektteams wird jedenfalls erwartet, dass sie diese Aspekte in ihre Entscheidungen einbeziehen und den für das Unternehmen jeweils optimalen Pfad wählen.

Damit das Kern-Projektteam die Verantwortung überhaupt übernehmen kann, ist es Voraussetzung, dass die jeweiligen Führungskräfte die Verantwortung dem Projektteam übertragen. Dies wiederum erfolgt nur dann, wenn klare, geteilte Ziele definiert werden und die Führungskräfte die Teams auch tatsächlich eigenständig arbeiten und im Rahmen der Vereinbarung Entscheidungen treffen lassen. Erhält ein Projektteam zwar die Budget- und Zeit-Verantwortung, nicht jedoch die Befugnis, die inhaltlichen Entscheidungen selbst zu treffen (z.B. Auswahl des Technologiepfads, Positionierung des Produkts), wird das Projektteam nie wirklich die Verantwortung übernehmen können.

Neben dem „Arbeiten-Lassen“ während des Projekts ist es wichtig, der Verantwortung eines Teams auch nach erfolgter Markteinführung eines neuen Produkts oder Services Rechnung zu tragen. Im Falle eines Projekterfolgs sollte das Team den Erfolg auskosten und die Lorbeeren ernten dürfen. Sollte das neue Produkt hinter den Erwartungen und Prognosen zurückliegen, liegt es weiterhin am Projektteam, das neue Produkt anzuschieben und damit den Erfolg zu suchen. Sollte sich dieser dennoch nicht einstellen, liegt es auch in der Verantwortung des Teams, auszuarbeiten, welche Aspekte des Projekts in Zukunft besser gemacht werden können und sollen.

Dem Ansatz „Lean Startup“ folgend kann dem Projektteam nicht nur die Verantwortung für ein einzelnes Produkt, sondern die Entwicklung und Vermarktung von aufeinander folgenden Produkt-Releases (Minimum Viable Products) übertragen werden. In diesem Fall wird das Projekt zu einem Programm, das einerseits eine ganze Palette von ähnlichen, sich ergänzenden oder aufeinander abgestimmten Produkten enthält oder andererseits eine ständige intensive Weiterentwicklung in Form regelmäßiger Updates und Upgrades enthält. Solche Programm-Management-Organisationen werden dann zwar wie bereits beschrieben gemanagt, kennen jedoch per se kein „Projekt“-Ende. Es handelt sich dann um interne Ventures bzw. kleine Business Units.

Agile Development fordert und fördert die Selbstorganisation von Teams. Die Führungskraft soll das Team möglichst eigenständig arbeiten lassen und nicht während der Projektphasen (Sprints) „die Dynamik der Teamarbeit stören“. In einem System, das bisher nach dem Prinzip „Vertrauen ist gut, Kontrolle ist besser“ gelebt hat, ist dies eine bedeutende Herausforderung – und zwar für beide Seiten. Projektteams, die unter dieser Prämisse gearbeitet haben, haben erfahren, dass etwaige Fehler durch die Führungskräfte aufgedeckt und abgefangen werden. Wir haben beobachtet, dass sich unter diesen Voraussetzungen die Projektteams oft weniger kritisch und intensiv mit dem Projekt auseinander setzen. Kritische Entscheidungen werden – wie gelernt – „nach oben“ eskaliert.

Die Führungskräfte eines solchen Systems sehen sich ihrerseits in der Rolle, die Fehler der Projektteams aufzudecken und zu korrigieren. Hierzu ist eine enge „Betreuung“ der Projekte und häufiges, regelmäßiges Rapportieren des Projektteams notwendig. Die Führungskraft hält die Kontrolle über das Projekt und trägt schlussendlich auch die Verantwortung dafür.

Die neue Führungskraft

Gehen wir davon aus, dass die Führungskräfte willens und auch fähig sind, das entsprechende Umfeld für diese neuen Innovationsansätze zu schaffen. Die Projektteams arbeiten eigenständig, selbstverantwortlich und agieren im Sinne des Unternehmens. Welche Rolle bleibt den Führungskräften dann noch?

Zunächst bleibt die herkömmliche Rolle der Führungskraft als Gatekeeper bestehen. Das ebenfalls interdisziplinäre Gatekeeper-Team entscheidet gemeinsam, welche Projekte umgesetzt werden sollen. Entsprechend den strategischen Prioritäten ordnen sie den Projekten Ressourcen zu und vereinbaren mit jedem Projektteams die Ziele und den Rahmen für das Projekt.

Die neuen Innovationsansätze verändern die Gatekeeper-Rolle insofern, als dass sich die Gatekeeper stärker auf die Projektteams verlassen bzw. die Fähigkeit entwickeln müssen, die Belastbarkeit der Entscheidungsgrundlagen (Deliverables) einzuschätzen und sie im richtigen Maß zu hinterfragen. Die Aufgabe des Gatekeepers wird insbesondere bei größeren, riskanteren Projekten zunehmend jener eines Venture Capitalists ähneln.

Eine wichtige Rolle der Führungskraft besteht im Anleiten der fachlichen und persönlichen Weiterentwicklung eines Mitarbeiters. Wenn die Führungskraft dem Imperativ des „Arbeiten-lassens“ folgt, wird sie weniger Berührungspunkte mit dem Mitarbeiter haben. Ein fachlich-persönliches Führen wird damit schwieriger.

Damit die Mitglieder eines Kern-Projektteams auch wirklich Verantwortung für das Projekt übernehmen können, müssen diese bedeutende Anteile ihrer Arbeitszeit dafür einsetzen dürfen. Im agilen Entwickeln gibt es die Forderung, dass die Kern-Projektmitglieder ausschließlich an diesem einen Projekt arbeiten (und kein zusätzliches Tagesgeschäft haben).

Es gibt Vorschläge, dass der Projektleiter diese Führungsfunktion mit übernehmen soll. Da der Projektleiter typischerweise jedoch nicht die fachliche Expertise des Projektmitarbeiters teilt, ist ein fachliches Anleiten durch den Projektleiter so gut wie nicht möglich.

Das fachliche Führen von Mitarbeitern bleibt sinnvollerweise beim fachlichen Vorgesetzen – allerdings mit einem etwas anderen Selbstverständnis: die Führungskraft wird zum fachlichem Coach mit Übersicht und viel persönlicher Erfahrung. Inwieweit die fachliche Führungskraft auch als persönlicher Mentor angesehen wird, hängt wohl von der zwischenmenschlichen Beziehung ab. Manche Unternehmen haben zur Förderung der persönlichen Weiterentwicklung ein Sponsoren-System eingeführt. Persönliche Sponsoren bzw. Mentoren können dann auch fachübergreifend gewählt werden.

Insbesondere die direkten Führungskräfte der Projektmitarbeiter werden künftig noch wesentlich stärker als heute die Verantwortung für die Rekrutierung und Weiterbildung eigenständiger, selbstverantwortlicher und fachlich starker Projektmitarbeiter übernehmen. Sie werden weniger im operativen Projektgeschäft mitwirken, als vielmehr strategisch die zukünftigen Anforderungen hinsichtlich Ressourcen und Know-how managen.

Bedürfnisse der jungen Fachkräfte – Generation Y / Millennials

Die Art und Weise, wie in Zukunft geführt wird, hängt nicht zuletzt auch von den Personen ab, die sich führen lassen wollen. Aktuell wachsen mit der „Generation Y (Millennials)“ (Jahrgänge 1980 bis 2000) Arbeitnehmer mit einem neuen Arbeitsstil heran. Laut einer Studie der Privat-Hochschule Göttingen zeichnen sich die Mitglieder dieser Gruppe durch folgende Merkmale aus:

  • Die Arbeit muss Spaß machen Millennials sind lernbereit und arbeitswillig – aber die Forderung nach Privatleben ist sehr ausgeprägt.
  • Millennials sind flexibel und anpassungsbereit, bevorzugen eine selbständige und unabhängige Arbeitsweise
  • Führungspositionen sind nicht mehr so wichtig, eher Fachlaufbahnen und projektbezogenes Arbeiten

Diese Charakteristika passen unbestritten besser zu den neuen Innovationsansätzen als zu einem klassischen Führungs- und Kontroll-Verständnis.

Zusammenfassung

Neue Methoden im Innovationsmanagement bringen Rollenwechsel sowohl für Projektmitarbeiter als auch für deren fachliche Führungskräfte mit sich. In welcher Form und mit welchem Selbstverständnis in Zukunft Mitarbeiter geführt werden, hängt von der Intensität der Adaption von neuen Methoden, der Unternehmenskultur und von den Anforderungen und Bedürfnissen der jungen Fachkräfte ab.

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Neuprodukt-Projekte: kleines Potenzial versus großes Risiko?

Wie kann sichergestellt werden, dass in einen Innovationssystem tatsächlich nur die Projekte mit dem größten Potenzial die Gates passieren? Bevor wir Kriterien zur Bewertung von Ideen und Neuprodukt-Projekten einsetzen, muss festgelegt werden, was wir mit der Bewertung überhaupt erreichen wollen. Bei der Priorisierung von Innovationsprojekten spielen zwei wesentliche Gedanken eine wichtige Rolle:

  • welches Potenzial steckt in einem Neuproduktprojekt, und
  • welches Risiko gehen wir damit ein.

Ziel der Anwendung der Kriterien ist in diesem Fall jene Projekte zu identifizieren, die das höchste Potenzial mit dem geringsten Risiko vereinen. Dies lässt sich mathematisch relativ einfach darstellen, in dem wir das Potenzial z.B. als Net Present Value (Netto-Barwert) bewerten und diesen Wert mit den Erfolgswahrscheinlichkeiten multiplizieren. Dann reihen wir die Projekte nach dem resultierenden Wert. In zahlreichen Unternehmen wird die Priorisierung der Projekte ähnlich gehandhabt.

Diese Überlegung hat einen kleinen Schönheitsfehler. Wir wissen nämlich eines mit ziemlicher Sicherheit: die zugrunde liegenden Zahlen der eben angestellten Rechnung sind falsch. Es liegt in der Natur der Neuproduktentwicklung, dass wir insbesondere in der frühen Phase mit dem Fehlen von Informationen und somit mit einer hohen Unsicherheit zu kämpfen haben. Umsatz- und Preisschätzungen vorzunehmen, bevor überhaupt klar ist, wie das neue Produkte oder die neue Dienstleistung überhaupt positioniert ist, oder mit welcher Technologie diese umgesetzt wird, grenzt an Kaffeesudleserei.

Insbesondere bei ambitionierten Innovationen ist eine finanzielle Bewertung in den frühen Phasen daher schwierig, da die Belastbarkeit der Annahmen oft gering ist. Während es für Produktverbesserungen klare Orientierungen gibt, wie z.B. aktuelle Marktpreise, Absatzmengen des Vorjahres oder nachgewiesene Produktionskosten, können für radikale Innovationen oft nur Annäherungen auf Basis von beispielsweise Nutzenüberlegungen oder Marktgröße gemacht werden.

Über die finanzielle Bewertung hinaus gibt es wissenschaftlich nachgewiesene Indizien, die darauf schließen lassen, wie das Potenzial und das Risiko eines Projekts zu bewerten sind. So verwundert es beispielsweise nicht, dass jene Projekte erfolgsträchtiger sind, die

  • einen neuen, bedeutenden und gut kommunizierbaren Nutzen für die Zielgruppe haben,
  • einen klaren Wettbewerbsvorteil haben und in ihrer Art einzigartig sind,
  • auf einen attraktiven, großen Markt mit hohem Wachstum, wenig Wettbewerb und hohen Margen abzielen.
0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Kluges Gatekeeping: Qualität der Projekte versus Quantität?

Gute Ideen sind nicht das knappe Gut. Entscheidend ist, was mit ihnen geschieht. Ein funktionierendes Innovationssystem kann man unter anderem daran messen, wie viele Projektabbruch-Entscheidungen in den frühen Gates (1 bis 3) getroffen werden. In vielen Unternehmen „beseitigen“ die Gatekeeper Projekte nicht, sondern „verwunden“ sie bloß, indem sie ihnen Ressourcen entziehen.
Kern des Risikomanagements eines Stage-Gate® Prozesses ist das Trichter-Prinzip: in viele Ideen/Konzepte zu Beginn ein wenig investieren, um dann sukzessive jene Neuprodukt-Projekte auszuwählen, in welche dann viel investiert wird. So wird die Spreu vom Weizen getrennt, und echte Innovationen entstehen.
Warum Projekte mit wenig Potenzial nicht gestoppt werden, auch wenn es unklug ist, lässt sich anhand von fünf Hauptgründen erklären:
1. Man hat schon viel Zeit und Geld in das Thema investiert.
2. Das Projekt ist auf Roadmap bzw. im Budget und damit „gesetzt“.
3. Unverlässliche Informationen und Angst vor falscher Entscheidung.
4. Keine Methode für Projektabbruch-Entscheidungen.
5. Hohe emotionale Bindung: Projektmitarbeiter haben „Herzblut“ im Projekt, Führungskräfte schützen ihre „Lieblingsprojekte“.
Stark umgesetzte Stage-Gate®-Prinzipien (wie etwa ausgeprägte Marktorientierung, Kundenintegration oder frühe Produkt- und Projektdefinition) sind auch ein Schlüssel zu „großen“ Innovationen. Dies erfordert von vielen Personen in der Organisation ein hohes Maß an Disziplin. Denn vor allem die Gates funktionieren oft nicht so, wie gedacht. Genau daran krankt dann auch das ganze Innovationsmanagement: Gates verkommen zu Meilensteinen, die vornehmlich dem Austausch des Projektstatus dienen. Die Folge: zu viele Projekte laufen parallel. Die Ressourcenausstattung je Projekt schrumpft, die Projektarbeit leidet, die Time-to-Market steigt, und vielversprechende Innovationsprojekte „dümpeln“ vor sich hin. Die dadurch entstehenden „Kosten“ in Form von entgangenen Umsätzen und Deckungsbeiträgen werden gerne übersehen.
Um große, ambitionierte Innovationsvorhaben voranzubringen, sind intelligente Gates notwendig, die nach folgenden fünf Prinzipien funktionieren:
• Entscheidungen anhand der richtigen Kriterien treffen.
Was ist für Ihr Unternehmen richtig? Wenn es darum geht, mit Innovationen mehr als inkrementell zu wachsen, braucht Ihre Firma eine kühne Innovationsstrategie, die auf echte Neuerungen und mutige Konzepte abzielt. Die Kriterien zur Bewertung und Priorisierung von Innovationsthemen und -projekten müssen genau diese Strategie abbilden und sollten nicht „durch die Hintertür“ die schnellen, kleinen, risikoarmen Projekte favorisieren.
• Sich von Unsicherheit nicht abschrecken lassen …
… sondern ihr aktiv begegnen. Dazu gibt es zahlreiche Möglichkeiten, z.B.
 Vergleiche, Analogien und Erfahrungen mit ähnlichen Aufgabenstellungen als „Anker“ für die Einschätzung des neuen Projektes verwenden.
 – Nicht der Illusion der sicheren Entscheidung nachjagen, sondern durch rasches Konkretisieren von Teilaspekten, schnell und früh im Projekt lernen und damit die die Sicherheit schrittweise erhöhen.
• Die richtige Informationsqualität sicherstellen.
Wir meinen hier nicht das Prinzip „je mehr desto besser“ sondern empfehlen den Fokus genau auf jene Informationen zu legen, die das Projekt voranbringen. Das heißt,
 – nicht das dokumentieren, was ohnehin klar ist und Erwartungen bestätigt, sondern gezielt nach Überraschungen, Widersprüchen und möglichen Stolpersteinen suchen.
 – schon zu Beginn das Projekt zu Ende denken, um später Verzögerungen und Schleifen im Projektablauf zu vermeiden und nicht z.B. aufgrund von Beschaffungsengpässen die Markteinführung zu verzögern.
• Die Innovationskraft der Beteiligten nutzen und pflegen.
Ambitionierte Innovationen entstehen vor allem dann, wenn Menschen mit unterschiedlichem Wissen und Erfahrungshintergrund miteinander intensiv kommunizieren. Deshalb muss auch bei Gate-Entscheidungen genügend Zeit und Raum geschaffen werden, damit Projektleiter und –team sowie Entscheidungsträger einen konstruktiven Dialog für eine kluge Entscheidung führen können.
Eine Kultur, die ehrgeizige Innovationen hervorbringen soll, muss auch Risiko und Flops zulassen. Damit Menschen auch nach Projektabbruch-Entscheidungen weiter innovativ sind, gilt es
 – Erfolg nicht nur am „Go“ messen sondern auch Beiträge zu rechtzeitigen, richtigen Projektabbruchentscheidungen anerkennen und als Erfolge feiern.
 – die Gründe für Entscheidungen zu kommunizieren und den Entscheidungsprozess transparent zu gestalten.
• Mit echtem Commitment die Erfolgsgrundlagen schaffen.
„Wasch mir den Pelz, aber mach mich nicht nass“ funktioniert bei ambitionierten Innovationsprojekten nicht, denn
 – eine Idee kann nur erfolgreich werden, wenn die notwendigen Ressourcen investiert werden. Deshalb müssen jene Führungskräfte, die im Besitz dieser Ressourcen sind, verantwortungsvoll entscheiden und dazu stehen.
 Dies braucht angesichts unvollständiger Information und herausfordernder Themenstellungen auch Mut, Geduld und langen Atem.
0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Agiles Vorgehen in der Frühphase der Produktinnovation – ein Erfahrungsbericht

Agiles Projektmanagement hat in den letzten Jahren Einzug in die Neuprodukt-Entwicklung auch jenseits der Software gehalten. Dabei wird die ursprüngliche Methode (z.B. Scrum) mal mehr mal weniger an die Besonderheiten der jeweiligen Industrie und an die Kultur des Unternehmens angepasst.
Es ist noch nicht abzusehen, ob und wenn ja wie sich die Methode schließlich bei der Entwicklung von physischen Produkten, Dienstleistungen und Geschäftsmodellen durchsetzen wird. Die Entwicklung des agilen Projektmanagements scheint derzeit seiner eigenen Spielregel zu folgen: schnell zu etwas Funktionierendem gelangen, dieses mit Anwendern testen, aus der Erfahrung lernen und die Methodik weiterentwickeln.

Dieser Erfahrungsbericht beschreibt einen solchen Lernzyklus des Einsatzes von agilem Projektmanagement in der Entwicklung von physischen Produkten.

In einem früheren Beitrag haben wir schon einmal ausgeführt, dass agiles Vorgehen insbesondere in einem ungewissen Projektumfeld einen hohen Nutzen stiftet. Agiles Projektmanagement müsste sich also besonders gut für die frühen Phasen der Entwicklung innovativer Produkte eignen. In der Softwareentwicklung liegt der Einsatzbereich agiler Methoden vornehmlich in der Entwicklungsphase und danach. Für die davor liegenden Analyse- und Konzeptionsphasen bieten Scrum & Co kaum methodische Unterstützung.
Sechs Projektteams aus zwei Unternehmen (eines aus dem Bereich Daten- und Energieübertragung, das andere ein Hersteller von Laborgeräten) haben sich gemeinsam mit five is der Herausforderung gestellt, Prinzipien und Werkzeuge aus dem agilen Methodenkoffer in den frühen Phasen (von der Idee bis zur Freigabe der Entwicklung) anzuwenden.

Folgende Erfahrungen und Erkenntnisse haben wir dabei gewonnen:

  • Wie auch im klassischen Stage-Gate®-System gefordert, arbeiteten wir mit interdisziplinären Teams. Es war immer mindestens eine Person aus Entwicklung, Produktmanagement und Fertigungstechnik, im einen oder anderen Projekt auch noch aus dem Einkauf im Team. Die bislang in diesen Unternehmen gelebte Praxis war, dass zunächst die „Marktseite“ ein Lastenheft definiert, welches dann die „Technikseite“ zu einem Pflichtenheft vervollkommnet. Die agile Zusammenarbeit hat alle Teammitglieder „gezwungen“, sich gemeinsam sowohl mit den marktseitigen als auch den technischen Aspekten des Projekts intensiv auseinanderzusetzen. Das Werkzeug Innovation Project Canvas hat diesen Prozess massiv unterstützt und beschleunigt.
  • Aus den Ergebnissen der Arbeit mit dem Innovation Project Canvas haben die Projektteams ein Project Backlog aufgebaut und die wichtigsten Projektaufgaben priorisiert. Das Project Backlog bestand aus 3 Bereichen:
    • Product Backlog: Dieses beinhaltete alle für das Produkt relevanten Aspekte (z.B. Kundenbedürfnisse, Anforderungen, Spezifikationen, etc.). Zu Beginn der Projekte war dieses noch ziemlich leer.
    • Risikomanagement: Hier wurden alle notwendigen zu erarbeitenden Erkenntnisse (z.B. Aussagen zu möglichen Verletzungen von Patenten) gesammelt, welche die Ungewissheit beseitigen bzw. das Risiko des Projekts reduzieren sollten.
    • Rahmenbedingungen: Hier wurden vom Team getroffene Grundsatzentscheidungen (z.B. Mindestanforderungen an die Qualität) sowie Abgrenzungen (z.B. Fokussierung auf Europäischen Markt) festgehalten und somit immer im Blickfeld des Teams gehalten.
  • Kernelement des agilen Vorgehens waren jeweils Sprints (Takte) von 2 Wochen.
    • Jeder Sprint wurde mit einem Kick-off-Meeting gestartet. In diesem wurde zunächst geklärt, welcher Projektmitarbeiter wie viel Zeit in den 2 Wochen des Sprints in das Projekt investieren kann. Konnte eine Person weniger als einen Tag pro Woche einbringen, nahm dieses Projektmitglied an diesem Sprint nicht teil und war angehalten seine verfügbaren Zeiten im nächsten Sprint zu bündeln.
    • Unter Berücksichtigung der verfügbaren Ressourcen definierten die Projektteams die Ziele für den Sprint. Hierzu wurden nach dem Motto „das Wichtigste zuerst“ jene Aspekte gewählt, die das Projekt am schnellsten voran brachten. Zu jedem Ziel definierten die Teams außerdem, welche Qualität für die Zielerreichung notwendig ist (Definition of Done), und wer überprüfen soll, ob diese erreicht wurde. Diese Ziele wurden in ca. 10 bis 20 Teilergebnisse heruntergebrochen und auf einem physischen Sprint-Backlog aufgelistet. Manche Teams nutzten das Kanban-System des Sprint-Backlogs ständig, andere zogen es erst im Sprint-Review nach. Der empfundene Nutzen des Kanban-Systems hielt sich bei allen Teams in Grenzen.
    • Eine wichtige Erkenntnis aus den ersten Sprints war, dass jene Teams deutlich bessere Ergebnisse erzielten, die einen gemeinsamen Projektraum nutzten und einen Großteil der Projektarbeit koloziert in einem gemeinsamen Projektraum erledigten. Um diesen Effekt möglichst gut zu nutzen, reservierten sich einige Teams einzelne Tage (z.B. Dienstag und Donnerstag) als Projekttage. Die restliche Woche konnten die Teammitglieder ihrem Tagesgeschäft oder weiteren Projekten nachgehen.
      Die meisten Teams trafen sich dann zweimal pro Woche zu einem kurzen Standup-Meeting, um den Projektfortschritt auszutauschen und ggf. Probleme im Vorankommen zu lösen.
    • Im abschließenden Sprint-Review wurde das Ergebnis des Sprints überprüft. Neue Erkenntnisse aus den Aktivitäten des Sprints führten immer wieder zu neuen Einträgen im Project Backlog. Dieses wurde ebenfalls im Sprint-Review auf den neusten Stand gebracht.
      Das Project-Backlog bietet einen guten Blick nach vorne. Es eignet sich als physisches Werkzeug an der Wand, jedoch weniger gut zur Dokumentation. Einige Projektleiter haben die Elemente auf den Backlogs parallel in eine Excel-Liste übertragen und somit eine saubere Dokumentation gewährleistet.
    • Am Ende jedes Sprint-Reviews reflektierte das Team die Arbeitsweise des Sprints und überlegte, wie es noch besser und schneller zusammenarbeiten kann. Für den nächsten Sprint nahm sich das Team dann bestimmte Anpassungen oder Veränderungen der Arbeitsweise vor. Dies führte in den Teams sehr schnell zu einer Verbesserung der Zusammenarbeit. So wurde z.B. der Nutzen von kolozierter, zeitlich paralleler Zusammenarbeit in den ersten Sprints erkannt und in den darauf folgenden verbessert.
    • Bei der Vorstellung der Methodik ist das Instrument des Burndown-Charts gut angekommen. Allerdings mussten wir dann in der Praxis feststellen, dass ein Burndown-Chart in der Frühphase eher demoralisierend wirkte. Die Projektplanung war zu Beginn des Projekts noch vage. Vielfach war noch nicht einmal der zu beschreitende technologische Pfad bekannt. Im Hinblick auf den weiteren Projektverlauf kamen eher neue Aufgaben und Aktivitäten hinzu. Sprich: der Chart-Verlauf entsprach weniger einem Burn-down sondern viel mehr einem Pile-up.
      Das bedeutet nicht, dass auf eine Gesamtprojekt-Planung verzichtet wurde. Die Teams gaben sich aber mit einer sehr groben Planung zufrieden.

 

Der Mehrwert des agilen Vorgehens wurde von den Projektteam-Mitgliedern durchaus unterschiedlich gesehen: von Begeisterung bis Ablehnung war alles dabei.

  • Ziemlich einig waren sich die Projektteam-Mitglieder, dass die enge Zusammenarbeit unterschiedlicher Disziplinen in der frühen Phase zu einem besseren Verständnis der Projektziele, einem direkteren Informationsaustausch und damit zu einer Beschleunigung geführt hat. Ob dieser Nutzen jedoch dem agilen Vorgehen oder einfach nur einer besseren Projektorganisation zuzuschreiben wäre, bestand jedoch Uneinigkeit.
  • Von einigen Projektteam-Mitgliedern wurde angezweifelt, ob agiles Vorgehen mit der Effizienz einer sauberen Planung mithalten könne – vorausgesetzt das klassisch durchgeführte Projekt würde ähnlich vorteilhafte Rahmenbedingungen vorfinden, wie jene Pilotprojekte.
  • Jene Projektteams, die sich voll auf das agile Vorgehen einließen, berichteten von einem neuen, attraktiven „Projektgefühl“: motiviertes Miteinander und viel Eigeninitiative der Teammitglieder wurden in diesem Zusammenhang erwähnt, oder auch, dass es leicht gefallen sei diszipliniert zu arbeiten.

Alles in allem wurden die gemachten Erfahrungen als wertvoll bezeichnet. Die meisten Projektteams sprachen sich außerdem für weitere Pilot-Einsätze des agilen Vorgehens in der frühen Phase aus.

 

Unsere Erkenntnis aus diesen Pilotprojekten lautet:

  • Agiles Vorgehen funktioniert in der frühen Phase der Neuprodukt-Entwicklung. Es eignen sich aber längst nicht alle Aspekte und Instrumente aus der „Scrum-Welt“. Im Fokus erster agiler Gehversuche sollten folgende 3 Elemente stehen:
    • Im Zentrum des agilen Arbeitens steht eine – einem Herzschlag gleiche – Taktung der Projektarbeit. Vor jedem Takt / Sprint überlegt das Projektteam, welche Erkenntnisse bzw. Ergebnisse das Projekt am besten vorwärts bringen.
    • Diese setzt sich das Team als Ziele für den Takt, abhängig von der Ressourcenausstattung. Gemeinsam beschäftigen sich die Teammitglieder intensiv damit, welche Qualität das Ergebnis haben soll, damit das Ziel als erreicht zu werten ist. Dies gibt klare Orientierung und vermindert die Gefahr, dass zu aufwändig bzw. zu oberflächlich gearbeitet wird.
    • Aus der Erfahrung eines jeden Sprints schöpft das Projektteam Potenziale für die Verbesserung der weiteren Zusammenarbeit im Projekt. Schwierigkeiten, Unzufriedenheit oder fehlende Koordination und Kommunikation werden sehr früh erkannt und unmittelbar angegangen.
  • Wir haben mit mehreren Projektteams die Erfahrung gemacht, dass die „Scrum“-Sprache schlecht angekommen ist oder teilweise schon anders besetzt war. Wir empfehlen deshalb, die Begrifflichkeiten flexibel zu handhaben und nicht allzu missionarisch Begriffe wie „Sprints“, „Project-Owner“, „Scrum-Master“, etc. einzuführen.
  • Die erfolgreiche Einführung von agilem Projektmanagement in der frühen Phase von Neuprodukt-Projekten hängt nicht zuletzt vom Führungsstil des mittleren und oberen Managements ab. Das Projektteam muss das Projekt eigenverantwortlich, und ohne ständig Rechenschaft ablegen zu müssen, vorwärts treiben können. Ansonsten werden zwar der Form nach agile Instrumente genutzt, ein tatsächlich agiles Vorgehen und damit dessen Nutzen verhindert.

Wenn Sie mehr über agiles Stage-Gate® erfahren wollen, besuchen Sie eines der folgenden Seminare oder kontaktieren Sie uns direkt.

 

0 Kommentare

* Pflichtfelder bitte unbedingt ausfüllen

Innovationskraft stärken ist unsere Mission. Innovationserfolg und Innovationsmanagement ist unsere Expertise. Fünf Erfolgsfaktoren dazu bewegen wir gemeinsam mit unseren Kunden durch Beratung, Coaching und Training:

Wir begleiten innovative Entwicklung mit Hirn und Herz: Mit Know how und langjähriger Erfahrung in Unternehmensberatung, Change Management und Training, mit Best-Practice-Werkzeugen, Begeisterung und Humor unterstützen wir Führungskräfte und Teams und steuern Veränderungsprozesse.

Von unseren Standorten in Vorarlberg und Berlin aus unterstützen wir Industrie- und Dienstleistungsunternehmen in Deutschland, Schweiz und Österreich sowie auch international in Kooperation mit Dr. Robert G. Cooper, einem der renommiertesten Vordenker für Produkt- und Technologieentwicklung.