Warum MedTech-Unternehmen Produktentwicklung verlernen – und was dagegen hilft

Veraltete Tools, verlorenes Know-how

Ein Unternehmen hatte vor über 10 Jahren eine Analyse-Software erstellt und als Add-On für ihr Diagnostik-Gerät an Kunden abgegeben. Seither wurde die Software am Leben gehalten – aber eher wie ein Koma-Patient. Das Team konnte vor allem Sprachunterstützungen und Chargenparameter ergänzen und freigeben. Es wurden weder die Programmiertools noch die verwendeten Bibliotheken aktualisiert.

Auch  die Arbeitsmethoden im Team entsprechen nicht den heutigen Standards: Best Practices des Software Engineerings wie Continuous Integration, UI & Integration Testing, automatisierte Unit-Tests, ein reifes Versionierungssystem wie GIT, usw., sind an dieser Software spurlos vorübergegangen. Die hohe Fluktuation junger und qualifizierter Fachkräfte in diesem Bereich ist dabei möglicherweise Folge und Symptom zugleich.

Wenn die Prozesse stimmen, aber die Richtung fehlt

Ein andere Unternehmen vertreibt seit über zehn Jahren eine Familie von klinischen Monitoren und entwickelt diese kontinuierlich weiter. Neben dem Austausch von abgekündigten Bauteilen werden regelmäßig Software-Erweiterungen, Zubehörkomponenten und Sensoren entsprechend den Anforderungen großer Tender ergänzt.

Die Arbeitspakete haben für sich genommen einen eher begrenzten Umfang. Sie finden in penibel ausdefinierten Arbeitsprozessen statt, die die Abhängigkeiten zwischen Abteilungen durch zwingende Prozessvorgaben berücksichtigen, und so die Arbeiten für einzelner Mitarbeiter in der F&E optimieren.

Symptomatisch ist hier, dass dennoch die übergreifende Planungssicherheit fehlt und dass Blockaden an den Schnittstellen und bei der Integration auftreten. Immer dann, wenn wichtige Termine drohen, werden alle (wirklich alle!) Entwickler und die benachbarten Einheiten wie Zentraleinkauf oder RA sehr aktiv, um dann unter Hochdruck doch ein Produkt-Release möglich zu machen.

Zusammenarbeit zwischen verschiedenen Disziplinen

Es sind nicht nur Elektronik, Softwareentwicklung und Mechanik, die nahtlos zusammenarbeiten müssen, was für sich schon zu Kommunikationsproblemen und Koordinationsaufwand führt. Es schließt ebenso die Spezialisten aus Requirements Engineering, QM, Regulatory Affairs, Einkauf, Fertigung, Clinical Research, usw. ein.

Wichtig ist es, Silo-Denken in Gewerken und Abteilungen unbedingt zu vermeiden. Ein Setup in interdisziplinären Teams mit Verantwortung (im doppelten Sinne von Accountability und Authority) für das Erschaffen von Teilfunktonen ist ein guter Ansatz, bricht aber oft mit gewachsenen Strukturen in einer Organisation.

Die zwei Leitlinien der agilen Produktentwicklung

One Team: 

Es ist die Aufgabe des Leaderships, dass alle Beteiligten das Projekt als ihre „Heimat“ betrachten. Als Führungskraft auf jeder Ebene ist es wichtig, nicht nur klare Ziele und Visionen sondern auch das eigene Commitment zu kommunizieren: 

• Die Geschäfts- oder R&D-Leitung für das Gesamtvorhaben
• Die Produktmanager für den fachlichen Benefit, den das Produkt in den ersten Versionen bringen wird
• Die Projektleiter und Architekten für die anstehenden Entwicklungsetappen und Lösungswege
• Die Team-Leads für die Verteilung von Aufgaben und Verantwortlichkeiten in den Teil-Teams

One Project: 

Ein weiterer elementarer Baustein, um das Commitment des Teams zum Entwicklungsvorhaben zu erreichen, ist die klare Zuordnung der einzelnen Personen zu dem Team. Zentrale Rollen sollten überwiegend nur mit diesem einem Projekt beauftragt sein. Denn: Wer nur 50% oder 60% dem Projekt zugeteilt ist, wird auch nur mit halbem Herzen dabei sein.

Es finden sich dann immer andere „noch wichtigere“ Aufgaben und Gründe, warum man nicht wie vereinbart am Projekt arbeiten konnte. Solche Mitarbeiter werden dann eher zu Zuschauern (ähnlich der Fabel vom „Chicken and Pig“, die auch oft in Erklärungen zu Scrum genutzt wird). 
 

Prioritäten und Qualitäts-Ansprüchen reifen

Eine Produktneuentwicklung durchläuft Phasen mit sehr unterschiedlichen Reifegraden und damit auch Zielsetzungen. Zu Beginn sind vor allem Konzepte und Machbarkeit wichtig, es geht um eher grundsätzliche Einschätzungen.  Später sind es punktuelle, aber sehr tiefgehende Untersuchungen und Design-Spikes. Dann wieder kommt eine Phase der breiten funktionalen Umsetzung; bevor die Arbeiten zuletzt dazu übergehen, das Produkt reif für die Serienfertigung zu machen.

Es ist wichtig, alle im Team kontinuierlich für diese unterschiedlichen Ziele zu motivieren und so sicherzustellen, dass alle an einem Strang ziehen und die gemeinsame Richtung kennen. Die Richtung, beispielsweise in Bezug auf Lieferantenqualifizierung vs. Rapid Prototyping, Re-Use alter Bibliotheken vs. neuer Software-Frameworks, usw. muss allen immer klar sein. Eine einmalige Ankündigung oder die Dokumentation im Entwicklungsprozess sind dafür nicht ausreichend. Entscheidend im Alltag der Entwickler sind eine klare inhaltliche und methodische Führung sowie eine kontinuierliche Kommunikation.

Planung und Transparenz

Gerade in diesem Bereich haben sich agile Methoden in meinen Projekten als sehr effektiv erwiesen. Frameworks wie SAFe® ermöglichen es auch in großen Projekten, dass mehrere Teams aufeinander abgestimmt handeln und dass Fortschritte, Ergebnisse oder Hindernisse kontinuierlich sichtbar sind. Ein strukturierendes Projektmanagement, Mitigation der Projektrisiken, kontinuierliche technische Integration, der Einsatz von Planungstools und nicht zuletzt Disziplin sind unumgänglich.

Sense of Urgency

Entwicklungsvorhaben mit mehreren Jahren sind für viele Beteiligte eine zu lange Zeitspanne. Die Projektziele und das fertige Produkt sind in zu weiter Ferne und subjektiv nicht greifbar. Vor diesem Hintergrund hat es sich bewährt, große Entwicklungsvorhaben in mehrere, größere Etappen von 6 - 12 Monaten Dauer mit greifbaren Zwischenergebnissen zu schneiden.

Beispielsweise könnte zuerst die Absicherung der technischen Machbarkeit mit Labormustern ein Etappenziel sein, dann im zweiten Schritt ein Funktions-Prototyp für die Hauptfunktionen, usw. Auch der Weg zu diesen Etappenzielen wird mit Zwischenzielen (Sprints und Produkt-Inkrementen) geplant, zu denen immer wieder das gesamte Projektteam Zulieferungen beisteuern muss. So können Motivation und Fokus, gemeinsames aktives Handeln und schnelle Entscheidungsfindung aufrechterhalten werden.