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

Wo Stage-Gate draufsteht, ist nicht immer Stage-Gate® drin

Wir sprechen mit vielen Führungskräften, Projektleitern und Innovationsmanagern über die Innovationspraxis in ihren Unternehmen. Oft hören wir dabei, dass Neuproduktprojekte selbstverständlich durch einen Stage-Gate®-Prozess gehen. Dies sei ja schließlich State-of-the-Art. Dazu nicken wir dann wissend und zustimmend.

Bei genauerem Nachfragen zeigt sich in diesen Gesprächen häufig, dass die Unternehmen nur einen Stage-Prozess und keinen Stage-Gate®-Prozess leben:
Für die Stages (Phasen) ist definiert und beschrieben, welche Aktivitäten in welcher Qualität mit welchen Methoden und Dokumentvorlagen durchzuführen sind.
Die Gates überschreitet man wie Meilensteine: Projektauftraggeber und Projektteam blicken auf den soeben absolvierten Stage zurück (Review) und haken Erledigtes ab. Der Unterschied zwischen Meilenstein und Gate wird leicht übersehen. Schade! Er ist der größte Hebel, um den vollen Nutzen eines Stage-Gate®-Systems auszuschöpfen.

Was Sie verlieren, wenn Sie in Ihrem Unternehmen Meilenstein-Meetings anstelle von Gates durchführen, und wie Sie Gates zu einem mächtigen Instrument in Ihrem Innovationsmanagement machen, erfahren Sie, wenn Sie weiterlesen.

Zwei zentrale Aufgaben von Gates

1. Risikomanagement
Stage-Gate®-Prozesse dienen dazu, das unternehmerische Risiko von Neuproduktentwicklungen „in den Griff zu bekommen“. Die Formel für das Risiko ist wie folgt:Unternehmerisches RisikoEs geht also um die Frage „Wie viel Geld setzen wir im schlimmsten Fall in den Sand?“. Zwei Überlegungen sind dazu hilfreich:

    • Wie viele Ressourcen müssen wir einsetzen, um das neue Produkt auf die Welt zu bringen?
      Man denke hier an Projektkosten (Arbeitszeit, Arbeitsmittel) sowie an Investitionen in Maschinen, Lizenzen, Produktionsanlagen, etc.
    • Wie hoch ist die Wahrscheinlichkeit des Scheiterns des Projekts?
      Diese hängt ab von der technischen Machbarkeit des Vorhabens im allgemeinen sowie von den eigenen Erfolgsvoraussetzungen (z.B. Know-How, Markt-Zugang). Ausserdem kann die Qualität der Projektarbeit (wie viel Tiefgang haben die Analysen, wie vollständig wird das Thema beleuchtet, …) das Projekt zum Fliegen oder zu Fall bringen.

Das Problem ist: Zu Beginn eines innovativen Projekts wissen wir meist wenig über tatsächliche Dauer, Kosten und Machbarkeit. Insofern ähneln Innovationsvorhaben dem Texas-Hold’em Pokerspiel. Zu Beginn einer Poker-Runde kenne ich als Spieler nur meine eigenen zwei Karten. Setze ich das Minimum, bekomme ich relativ viel zusätzliche Information: Ich darf drei weitere Karten sehen, die mir helfen abzuschätzen, wie erfolgreich ich mit meiner Hand in diesem Spiel sein kann. Will ich weiter mitmachen und Karte vier und fünf sehen, muss ich meist mehr Geld in die Mitte legen. So ist es auch im Neuproduktprojekt: In den frühen Phasen beschafft das Projektteam mit relativ geringem Ressourceneinsatz Informationen, um die Erfolgswahrscheinlichkeit besser beurteilen und den Ressourcenbedarf besser einschätzen zu können. Je weiter ein Projekt fortschreitet desto mehr muss man investieren, um voran zu kommen. Die Entwicklungsphase ist meist kostenintensiver als die vorangegangene Konzeptionsphase. Geht es in die produktionstechnische Umsetzung, wird es meist richtig teuer.

Unternehmerisch klug ist daher, wie beim Poker den Ressourceneinsatz für das Projekt zu staffeln und nicht schon am Anfang das ganze Budget auf den Tisch zulegen. Genau das geschieht in Gates. Meilenstein-Review-Meetings können dafür sorgen, dass das Projekt richtig gemacht wird. Ein Gate beantwortet immer auch die Frage, ob es (immer noch) das richtige Projekt ist und wie viel aufgrund des aktuellen Stands des Wissens und Projektfortschrittes weiter investiert werden soll.

2. Projekt-Durchführung mit voller Kraft

Unternehmen, in denen Gates nicht funktionieren, haben häufig zu viele Projekte mit zu wenig Ressourcen. Projektleiter und –teams sind überlastet, Budgets werden gekürzt. Die Projekte dauern länger. Versuchen die Projektteams dennoch, an den ursprünglichen Zeitplänen – verabschiedet unter der Annahme ausreichender Ressourcenausstattung – festzuhalten, leidet meist die Qualität der Projektarbeit. Dies führt wiederum zu mehr Risiko im Projekt und im schlimmsten Fall zu Flops am Markt, die man hätte vermeiden können.

Neben dem finanziellen Verlust und dem möglichen Image-Schaden für das Unternehmen besteht auch noch die Gefahr, Projektmitarbeiter zu verlieren. Entweder sie werden aufgrund der ständigen Überlastung krank oder verlassen frustriert das Unternehmen.

Gates sorgen dafür, dass jeder Stage realistisch geplant wird und Projektfreigaben nur erfolgen, wenn auch gewährleistet ist, dass die erforderlichen Ressourcen bereitstehen.

Woran man funktionierende Gates erkennt

Teilnehmer am Gate

Gates sind keine Projekt-Informationsmeetings für Interessierte. Am Gate nehmen ausschließlich jene Personen teil, die für die anstehende Entscheidung gebraucht werden. In der Regel sind es die Führungskräfte jener Personen, die im nächsten Stage im Projekt arbeiten sollen. Dabei ist sicherzustellen, dass diese Führungskräfte die notwendige fachliche Qualifikation und Erfahrung mitbringen, um das Projekt zu bewerten. Außerdem müssen die Gatekeeper gemeinsam die Befugnis besitzen, die notwendigen Ressourcen für den nächsten Stage freizugeben.

Neben den Gatekeepern sollte zumindest der Projektleiter, besser aber das gesamte Projektteam am Gate-Meeting teilnehmen. Auf diese Weise werden die getroffenen Entscheidungen für das Projektteam transparent und nachvollziehbar.

Ablauf eines Gates

Vor dem Gate:

Das Projektteam erarbeitet die sogenannten „Deliverables“: Ein Informationspaket als Grundlage für die Entscheidung über Fortsetzung oder Abbruch des Projekts. Es beinhaltet in der Regel Informationen zu Produktkonzept, Markt und Machbarkeit, zu Chancen und Risiken des Projekts, eine Wirtschaftlichkeitsbetrachtung sowie den Aktivitäten-, Zeit- und Ressourcenplan für den nächsten Stage.

Die Deliverables sollten maximal 10 Seiten umfassen. Andernfalls steigt die Gefahr, dass die Gatekeeper nicht die Zeit finden, diese vor dem Gate zu studieren. Details können zum Vertiefen und Nachlesen gesondert bereitgestellt werden.

Beim Gate-Meeting:

Beim Gate-Meeting wird ein dreistufiger Diskussions- und Entscheidungsprozess durchlaufen.

Diskussions- und Entscheidungsprozess

  • Zunächst beurteilen die Gatekeeper die Qualität der Projektarbeit des letzten Stages.
    Lässt sich auf Basis der bereitgestellten Information keine gute Entscheidung über das weitere Vorgehen treffen, lautet die Entscheidung „recycle“. Das bedeutet, das Projektteam geht in den letzten Stage zurück und erarbeitet die fehlenden Informationen in gewünschter Qualität.
  • Ist die Qualität der Projektarbeit ok, bewerten die Gatekeeper die Attraktivität des Projekts anhand erforschter Erfolgsfaktoren für Neuprodukte. Entsprechende Kriterien sind u.a. Strategie-Fit, Kundennutzen, Wettbewerbsvorteil, Marktattraktivität, technische Machbarkeit, wirtschaftliche Attraktivität. Jeder Gatekeeper beurteilt individuell anhand einer Scorecard die Attraktivität des Projekts. Die Bewertungen aller Gatekeeper werden dann miteinander verglichen. Die Diskussion fokussiert sich vor allem auf jene Kriterien, welche die Gatekeeper stark unterschiedlich bewertet haben.
    Wir haben schon öfters beobachtet, dass Unterschiede in der Bewertung des Projekts nicht zuletzt daher rühren, dass die Gatekeeper verschiedene Vorstellungen haben, was eigentlich Ziel des Projekts ist. Somit bietet das Gate eine gute Plattform ein einheitliches Verständnis dafür zu schaffen.
    Sind sich die Gatekeeper einig, dass das Projekt wenig attraktiv ist, wird es an dieser Stelle gestoppt.
  • Passt die Attraktivität des Projekts, geht es im dritten Schritt um die Freigabe der Ressourcen für den nächsten Stage. Manche Unternehmen werfen an dieser Stelle auch einen Blick auf das gesamte Neuproduktprojekte-Portfolio und ordnen das zu entscheidende Projekt gegenüber den anderen Projekten ein.
    Diskussionsgrundlage für die Timing- und Ressourcenentscheidung ist ein vom Projektteam vorbereiteter Plan für den folgenden Stage. Jede Führungskraft prüft (idealerweise schon vor dem Gate), inwieweit die Ressourcen (Personen und Budget) im geforderten Maß verfügbar sind. Nur falls ja, kann es eine „Go“-Entscheidung geben. Andernfalls ist die Entscheidung „Wait“: Das Projekt wird bis zu einem bestimmten Termin oder Ereignis (z.B. Abschluss eines anderen Projekts) auf Eis gelegt.

Alles in allem sollte ein gut vorbereitetes Gate-Meeting nicht länger als 90 Minuten dauern.

Emotionale Aspekte eines Gates

Bei all den formalen Aspekten eines Gates darf nicht vergessen werden, dass Gates insbesondere emotional eine Herausforderung sein können. Ein Projekt zu stoppen ist eine unangenehme Aufgabe, die den Gatekeepern viel abverlangt.

Möglicherweise hat das Projektteam „Herzblut“ in das Projekt gelegt. Eine Stopp-Entscheidung tut weh und stößt die Mitarbeiter vor den Kopf. Die Führungskräfte müssen klarstellen, dass der Projektabbruch kein Versagen des Projektteams bedeutet. Sonst wäre ja eine „recycle“-Entscheidung erfolgt. Vielmehr ist zu würdigen, dass das Projektteam mit seiner Arbeit und mit den bereitgestellten Informationen eine für das Unternehmen sinnvolle Entscheidung ermöglicht hat. Wichtig ist auch, dass die vom Stopp betroffenen Mitarbeiter nun neue, motivierende Aufgaben bekommen.

Häufig wäre es für Gatekeeper einfacher ein Projekt weiterlaufen zu lassen, in der Hoffnung, dass es vielleicht doch noch erfolgreich wird. Scheitert ein solches Projekt dann, kann man es immer noch unter „Lernerfahrung“ verbuchen. Mit dem Projektstopp nehmen die Gatekeeper dem Projekt die Möglichkeit, doch noch etwas zu bringen. Das erfordert mitunter mehr Mut. Die Stoppentscheidung ist aber für alle anderen laufenden Projekte wichtig. Durch Fokussierung und Konzentration der Ressourcen auf die attraktivsten Projekte steigen deren Erfolgschancen und verkürzt sich die Time-to-Market.

Praxisrelevanz

Dazu finden wir folgende Erfahrung interessant: five is veranstaltet seit zwei Jahren das Seminar „Beyond Stage-Gate®“ mit Prof. Cooper. Haupt-Thema ist dort, wie man Stage-Gate® mit neuen Ansätzen, wie agiles Entwickeln, Design Thinking oder Business Model Innovation erweitern und ergänzen sollte. Nach jedem Seminar fragen wir die Teilnehmer, welche Aspekte sie aus dem Seminar mitnehmen und in ihrem Unternehmen vordringlich umsetzen wollen. Die meisten Teilnehmer aus namhaften europäischen Unternehmen antworten: „Zunächst müssen wir unser klassisches Stage-Gate®-System, insbesondere die Gates zum Laufen bringen. Erst danach macht es Sinn, uns den neuen Methoden zu widmen!“

Das nächste Seminar „Beyond Stage-Gate®“ mit Prof. Robert G. Cooper findet am 17. und 18. Oktober 2016 in Darmstadt statt. Weitere Informationen finden Sie hier.

Wenn Sie Gates in Ihrem Innovationsprozess etablieren oder verbessern möchten, besuchen Sie eines der folgenden Seminare oder kontaktieren Sie uns direkt.

 

  1. 12. September

    Prima Zusammenfassung zu Gate meetings.
    Ich kann den Stimmen anderer Unternehmensteilnehmer nur beipflichten, dass erst einmal der klassische stage-gate und insbesondere die Gates zum Laufen gebraicht werden müssen, bevor man weiterführende Methodiken wie zum Beispiel Agiles Handeln austestet.
    MfG Christoph Broßmer
    Evonik Industries AG

    gepostet von Christoph Broßmer um 13:49 Uhr
  2. 13. Februar

    […] einem früheren Beitrag haben wir schon einmal ausgeführt, dass agiles Vorgehen insbesondere in einem ungewissen […]

  3. 22. Februar

    […] an earlier report, we explained that agile proceedings bring many benefits, especially in an uncertain project. […]

* 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.