Skip to content
All posts

30 jähriges Jubiläum von "The New New Product Development Game", Teil 7

“Subtle control
Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. Instead, the emphasis is on "self-control", "control through peer pressure", and "control by love'', which collectively we call "subtle control". Subtle control is exercised in the new product development process in seven ways:
1. Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary. (...)
2. Creating an open work environment. (...)
3. Encouraging engineers to go out into the field and listen to what customers and dealers have to say. (...)
4. Establishing an evaluation and reward system based on group performance. (...)
5. Managing the differences in rhythm throughout the development process. As mentioned earlier, the rhythm is most vigorous in the early phases and tapers off toward the end.
6. Tolerating and anticipating mistakes. (...) The key lies in finding the mistakes early and taking steps to correct them immediately. We've taken steps to expedite the trial production cycle for that reason. (...)
7. Encouraging suppliers to become selforganizing. Involving them early during design is a step in the right direction. But the project team should refrain from telling suppliers what to do. (...)”

Im Jahr 1986 haben Hirotaka Takeuchi und Ikujiro Nonaka ihr berühmtes Paper veröffentlicht, „The New New Product Development Game“. In ihrer Untersuchung schlugen die Autoren einen parallelen und ganzheitlichen Produktenwicklungsansatz vor, im Gegensatz zu einem seriellen, auf einzelne Phasen spezialisierten Entwicklungsansatz.
Als Takeuchi und Nonaka eine neue Herangehensweise für Produktentwicklung erläuterten, war die 3. Industrielle Revolution (der Einzug von Computertechnik) seit einigen Jahren voll im Gange.
Heute sind Digitalisierung, Industrie 4.0, Smart Factory, Internet of Things, Roboter-Mensch-Interaktion die Themen, welche in den Medien stark vertreten sind und viele Menschen beschäftigen. Dies wird in Deutschland die „4. Industrielle Revolution“ genannt und noch größere Umwälzungen als die Erschaffung des Internets werden vorausgesagt.

In dieser Reihe möchte ich Passagen des Original Papers zitieren und die Aussagen in Bezug zum Jahr 2016/2017 stellen.

***Teil 7***

Ein Projekt-Team, welches sich in Kontakt mit dem Komplexen Kontext (d.h. „Digitalisierung“, „IoT“ usw.) befindet, benötigt bei der Aufgabenbewältigung die Unterstützung des Umfeldes. Die Team-Mitglieder sollten daher den uneingeschränkten Support anderer haben und sich eine Umgebung schaffen können, welche ihre Chancen auf eine erfolgreiche Projektdurchführung erhöht.

Auch heutzutage halte ich eine ausgewogene Team-Zusammensetzung als essentiell für ein schlagkräftiges Projekt-Team. Ich habe es erlebt, dass Teams auf Basis von Abteilungen oder anderen Einheiten der Aufbauorganisation gebildet werden, ohne dass die persönlichen Charakterzüge berücksichtigt wurden. Ebenso habe ich es erlebt, dass Teams nur aufgrund von fachlichen Kompetenzen zusammengestellt wurden. Ein Team hatte z.B. große emotionale Probleme im Umgang miteinander, sodass eine konstruktive Zusammenarbeit über mehrere Wochen fast unmöglich war. Dieses Team war mit mehreren Personen aus zwei Abteilungen besetzt, die aufgrund der bisherigen, jahrelangen „Zusammenarbeit“ gegenseitige Vorbehalte aufgebaut hatten, die sich in Mistrauen und Vorurteile auf beiden Seiten manifestierten. Diese Konflikte kamen in manchem Meeting an die Oberfläche, nahmen viel Raum und Zeit ein und führten letztendlich zu Verzögerungen in der eigentlichen Projektumsetzung.

Sich anbahnende Eskalationen innerhalb des Projekt-Teams können frühzeitig erkannt werden, wenn regelmäßig die Zufriedenheit der Teamglieder abgefragt wird. Hierfür eignet sich die „Happiness-Metrik”: Die Team-Mitglieder werden gebeten, den Grad ihrer Zufriedenheit auf einer Skala von „1“ (sehr unzufrieden) bis „5“ (sehr zufrieden) anzugeben. Die Zufriedenheit kann für mehrere Dimensionen erfragt werden, z.B. Zufriedenheit mit der Rolle innerhalb des Projekt-Teams und Zufriedenheit mit der Firma generell. Ich habe diese Abfragen immer anonym durchgeführt, um eine individuelle Einschätzung zu bekommen, welche dann unabhängig von der Einschätzung der anderen Leute im Team ist. Falls sich die Zufriedenheit über längere Zeit bei 1 oder 2 einpendeln, kann dies ein Hinweis auf ein grundlegendes Thema mit der Situation sein, die besprochen werden sollte.

Ich kenne Organisationen, in denen es Personen aus den Entwicklungsabteilungen untersagt war, mit Anwendern oder Kunden in Kontakt zu treten. Dies kann für den Erfolg eines Projektes nur hinderlich sein. sollten systematisch abgebaut werden Diese „Reaktionen“ kommen oft in Form von Feedback auf das Projekt-Team zurück. Berührungsängste mit potenziellen Kunden und Usern sind hier fehl am Platz und sollten systematisch abgebaut werden Erfahrene Team-Mitglieder aus Marketing und Vertrieb können hier den Leuten ohne bisherigen Kundenkontakt helfen, diese Ängste abzubauen. Ein innovatives Unternehmen sollte Regeln überdenken, die einen solchen Kontakt verhindern.

Ein weiterer Erfolgsfaktor ist die sogenannte „Fehlerkultur“ eines Unternehmens. Problematisch sehe ich hier alleine schon die Wahl der Begrifflichkeiten. Es gibt für ein Team im Kontakt mit dem komplexen Kontext keine „Fehler“ ¹. Wenn ein innovatives Unternehmen neue Geschäftsprozesse, Produkte oder Dienstleistungen entwickeln will, muss allen Beteiligten klar sein, dass der Weg zum Erfolg ein ständiges Antesten von Lösungen ist und im Vorfeld kein Richtig und kein Falsch existiert. Daher sollten wir besser von Erfahrungen sprechen. Je aktiver ein Team ist, desto mehr Erfahrungen kann es machen und dadurch sein Verständnis vom Komplexen Kontext immer weiter ausbauen.

¹ Streng genommen stellt ja der Fehler eine Abweichung vom „Soll“ zum „Ist“ dar. Im Komplexen Kontext existiert aber kein „Soll“, denn es soll ja gerade erforscht werden, welche Maßnahmen funktionieren und das Projekt-Team seinem Ziel näher bringen, und welche nicht. Daher existiert zu diesem Zeitpunkt auch kein „Soll“, keine Abweichung und keine Fehler.