Agil am Limit: Wie Du mit AgileTrio agile Werte und Vorgehen im streng regulierten Umfeld umsetzen kannst

Von Jonathan von Wittern

Das Buch stellt den neuen Ansatz AgileTrio vor, der agile Methoden nahtlos mit ein regulatorische Framework kombiniert. Diese innovative Herangehensweise ermöglicht die erfolgreiche Einführung und kontinuierliche Entwicklung von zuverlässigen regulierten Softwareprodukten in schnellen Veröffentlichungszyklen, ein Ansatz, der auch im regulieren Umfeld immer bedeutsamer wird.

Die Leser werden auf eine Reise durch die Welt der Softwareentwicklung mitgenommen, beginnend mit einer eingehenden Untersuchung der Geschichte der jungen Disziplin. Das Buch beleuchtet dabei die beiden Welten: das klassische Vorgehen und das vorherrschende traditionelle Mindset, das in regulierten Umgebungen weit verbreitet ist, sowie das agile Vorgehen und das zugehörige Mindset das in der weniger regulierten Web- und Applikationsentwicklung vorherrscht.

Im Fokus stehen exemplarisch die verschiedenen Aspekte der Medizinischen Softwareentwicklung, wobei das Buch umfassend auf folgende Themen eingeht:

- Qualitätsmanagementsysteme
- Softwareentwicklung
- Risikomanagement
- Anforderungsmanagement
- Produktverifizierung
- Benutzerfreundlichkeit
- Informationssicherheit
- klinische Bewertung
- Bereitstellung und Verteilung
- Kennzeichnung
- Begleitdokumentation
- Produktlebenszyklus
- Überwachung nach Inverkehrbringen
- Informationssicherheit

Der Autor skizziert die notwendigen Rollen innerhalb der Produktentwicklung und verdeutlichen die damit verbundenen Aufgaben und Verantwortlichkeiten. Ein Schwerpunkt liegt dabei auf der effektiven Zusammenarbeit aller beteiligten Parteien, um eine erfolgreiche Marktzulassung für regulierte Produkte sowie die Erstellung einer umfassenden Technischen Dokumentation zu gewährleisten.

Inmitten der rasanten Digitalisierung der Gesundheitsbranche zeigt das Buch auf, wohin die Reise in Bezug auf die Produktentwicklung von regulierten Softwareprodukten führt. Es wirft dabei einen klaren Blick auf die damit verbundenen Herausforderungen und bietet konkrete Lösungsansätze.

• Sprache: Deutsch
• Herausgeber: tredition
• Erscheinungsdatum: 10. Nov. 2023
• ISBN: 9783384082886

Jonathan von Wittern

Ich schaue auf über 20 Jahre Berufserfahrung in regulierten Bereichen wie Medizintechnik, Luftfahrt und Automotive zurück. Meine Leidenschaft gilt der Medizintechnik. Zu wissen, dass Medizinprodukte das Leiden von Patienten lindern oder beseitigen können, ist für mich eine unglaubliche Motivation. Dabei durfte ich Erfahrung in den verschiedensten Unternehmensbereichen wie Produktion, technischer Service, hardwarenahe Softwareentwicklung, Qualitätsmanagement und Regulatory Affairs sammeln. Ich habe mit Weltmarktführern zusammengearbeitet aber auch mit Familienunternehmen und Startups.

Buchvorschau

1. Wie hat sich Softwareentwicklung verändert

Die Softwareentwicklung ist im Vergleich zu anderen Entwicklungsdisziplinen wie Hardware oder Mechanik noch relativ jung. Sie ist jedoch die abstrakteste Disziplin. Software kann nicht angefasst werden und ist oft schwer verständlich für Menschen, die keine Programmierkenntnisse haben. Um als Softwareentwickler*in verständlich zu sein, benötigt man neben Programmierfähigkeiten auch gute Kommunikationsfähigkeiten, um Sachverhalte zu veranschaulichen und zu dokumentieren. Es ist zudem wichtig zu verstehen, dass Software ohne Hardware nicht existieren kann. Dies wird zuweilen übersehen. Wenn es um angemessene Testtiefen geht, verwende ich oft den Spruch „Software läuft nicht in der Luft".

Die Hardware umfasst physische Komponenten, die benötigt werden, um Software zu speichern und auszuführen. Die Hardware verfügt in der Regel über Schnittstellen, die Ein- und Ausgänge ermöglichen. Diese Schnittstellen können Dateneingänge und -ausgänge sowie Aktoren und Sensoren sein. Die Hardware umfasst auch Speichereinheiten wie Mikrochips und Festplatten, Prozessoren sowie Eingabegeräte wie Maus oder Tastatur.

Die Software besteht aus Verfahren, die in Zusammenarbeit mit der Hardware bestimmte Aufgaben erfüllen. Es handelt sich um geordnete Anweisungen, die Veränderungen in der Hardware bewirken. Dadurch können wir mit der Hardware kommunizieren und interagieren. Menschen tun dies normalerweise über Nutzerschnittstellen. Aber auch andere Hardware oder Sensoren können mit der Hardware interagieren und über geordnete Anweisungen weitere Hardware oder Aktoren ansprechen.

Die Softwareentwicklung begann in den 1950er Jahren, in denen Software und Hardware als unterschiedliche Dinge betrachtet wurden. Es war auch die Zeit der ersten Transistoren, was die Möglichkeit bot, Schaltkreise immer kleiner zu machen. In den 1960er Jahren kamen die ersten Minicomputer auf und die Softwareentwicklung konnte breiter voranschreiten. Gleichzeitig stieg der Bedarf an Software. In den 1970er Jahren wurden mit den Mikrocontrollern Computer immer kleiner und leistungsfähiger.

Jedoch begann 1965 die sogenannte große Software-Krise, die bis etwa 1985 andauerte. In dieser Zeit wurden viele Probleme der Softwareentwicklung identifiziert und bekannt. Budgets und Zeitpläne gerieten regelmäßig außer Kontrolle. Fehlerhafte Software verursachte große Schäden und kostete zum ersten Mal auch Menschenleben. Ein Beispiel dafür sind die Strahlentherapieunfälle Anfang der 1980er Jahre, bei denen fehlerhafte Software dazu führte, dass Geräte eine tödliche Strahlendosis an Patienten*innen abgaben.

Das Wasserfallmodell entstand in dieser Zeit. 1970 veröffentlichte Winston W. Royce eine erste Publikation darüber. Das Ziel war, große Softwareprojekte besser kontrollieren und fatale Fehler vermeiden zu können. Dadurch sollten Kosten, Zeit und Ressourcen besser planbar und kontrollierbar werden.

Das Requirements-Engineering hat ebenfalls seine Ursprünge in den 1970er Jahren. Das Ziel war, Anwenderbedürfnisse durch systematische Anforderungsanalyse besser zu berücksichtigen und umzusetzen. Das Requirements-Engineering wurde entwickelt, um Projekte, die Kosten, Zeit und Ressourcen außer Kontrolle geraten lassen, zu vermeiden.

In den 1980er Jahren entstanden verschiedene Vorgehensweisen und Lösungen, die als „Silver Bullets angepriesen wurden, um die Software-Krise zu bewältigen. Doch in den 1990er Jahren setzte die Ernüchterung ein. Fred Brooks veröffentlichte einen Artikel Mit dem Titel „No Silver Bullet, in dem er argumentierte, dass keine einzelne Technologie oder Praxis innerhalb von zehn Jahren eine 10-fache Verbesserung der Produktivität bewirken würde.

Mit den 1990er Jahren begann der Aufstieg des Internets, was zu einer großen Nachfrage nach unkritischer und anwendungsbezogener Software führte. Die Softwareentwicklung wurde durch Skriptsprachen erleichtert. In dieser Zeit entstand auch das V-Modell als Weiterentwicklung des Wasserfallmodells, das moderate Iterationen ermöglicht. Das Requirements-Engineering entwickelte sich ebenfalls weiter. Die Unified Modeling Language sollte dabei helfen, Software zu modellieren, anstatt sie selbst zu programmieren. Es bot auch die Möglichkeit, Anforderungen visuell darzustellen, anstatt nur sprachlich.

Anfang der 2000er Jahre wurde die ISO/IEC 25000er Reihe [1] veröffentlicht. Sie stellt ein standardisiertes Werk für Anforderungen, Qualität und Bewertung von Softwareprodukten dar. Diese Anforderungen sind wissenschaftlich fundiert und entsprechen dem „Stand der Technik". Sie werden auch heute noch in der klassischen Softwareentwicklung angewendet.

Mit dem Aufstieg des Internets und der starken Nachfrage nach anwendungsbezogener und unkritischer Software wuchs auch der Frust bei Teilen der Softwareentwicklung über herkömmliche Methoden. Dadurch entstand bis 2001 das Agile Manifesto, das als Ursprung und Basis aller nachfolgenden agilen Vorgehensweisen, Prinzipien und Praktiken gilt.

Kanban hat seinen Ursprung bei Toyota und wurde in den 1940er Jahren zunächst in der Autoproduktion eingesetzt. In der Softwareentwicklung wurde es erst etwa 70 Jahre später, um 2010, erstmals angewendet. Kanban gilt als eine der radikalsten agilen Methoden, die jedoch nur mit großer Teamdisziplin gut funktionieren kann.

Scrum dagegen entstand bereits in den 1990er Jahren durch Jeff Sutherland und Ken Schwaber. Es wurde jedoch erst Anfang der 2000er Jahre bekannt, als beide Vordenker es zum ersten Mal publizierten. Scrum ist ein Time-Boxing-Verfahren, das von Natur aus Disziplin erfordert und als das erfolgreichste agile Vorgehensmodell gilt. Auch im agilen Vorgehen ist Anforderungsmanagement wichtig, jedoch oft direkter, leichter und unvollständiger.

Moderne Ansätze für agile Softwareanforderungen versuchen, systematische Ansätze anzubieten, die das Dokumentieren und Spezifizieren nicht überbetonen, aber dennoch eine Mindestspezifikation bieten. Oft wird die Dokumentation auf Organisationsebene auch als Anforderungsdokumentation für ein Produkt genutzt. Diese Ansätze sind relativ neu und weniger als zehn Jahre alt.

Heutzutage stehen wir vor den Herausforderungen der Digitalisierung in einer schnelllebigen Welt. Unsere Nutzung von Cloud-Services vermittelt uns den Eindruck, dass Hardwareressourcen unbegrenzt verfügbar sind. Software spielt eine zentrale Rolle und wird auch in kritischen Bereichen wie autonomen Fahren, Medizinischer Software, dem Internet der Dinge, maschinellem Lernen und künstlicher Intelligenz eingesetzt. Daher besteht ein wachsender Bedarf an agilen Methoden für streng regulierte Produkte.

Mein Ansatz, den ich in diesem Buch erläutere, ist AgileTrio, das Organisationen und Teams dabei helfen kann, regulierte und qualitativ hochwertige Software flexibel, anpassungsfähig und schnell zu entwickeln. Dabei sollen moderne agile Werte nicht vernachlässigt werden. Dazu wird Scrum mit einem regulierten Framework kombiniert. Darauf werde ich im Kapitel AgileTrio näher eingehen.

Das Bild zeigt die Geschichte der Softwareentwicklung. Es veranschaulicht, wie die wissenschaftlichen Errungenschaften der klassischen Softwareentwicklungen zusammen mit den neueren agilen Methoden und Erkenntnissen genutzt werden können, um die Softwareentwicklung zu verbessern.

In der Softwareentwicklung gibt es einen Trend zur „Deprofessionalisierung" aufgrund des zunehmenden Einflusses des Internets und mobiler Geräte. Immer mehr Menschen, die keine formale Ausbildung absolviert haben, beteiligen sich am Softwareentwicklungsprozess. Sie lernen das Programmieren autodidaktisch durch Bücher, Kurse oder Tutorials. Zudem entstehen durch Open-Source-Projekte und die globale Vernetzung große Communities, in denen Laien und ausgebildete Softwareentwickler zusammenarbeiten. Dabei werden Programmiersprachen immer einfacher und die Software-Hardware-Kopplung wird gelockert. Das Wissen um bewährte Techniken und die Bedeutsamkeit einer professionellen Ausbildung wird zunehmend inessenziell.

Auf der anderen Seite möchten auch regulierte Produkte und sicherheitskritische Anwendungen von den Möglichkeiten der Softwareentwicklung profitieren. Dadurch steigt die Nachfrage nach Standards und Qualitätssicherung in der Softwareentwicklung. Produkte und Systeme werden immer komplexer und die Software muss permanent mehr Funktionalität umsetzen. Heutzutage ist Software oft kostengünstiger als Hardware, sie altert nicht und ermöglicht eine einfachere Anpassung der implementierten Funktionalitäten.

Die Globalisierung führt dazu, dass Produkte in wachsendem Maße vom raschen Wandel gekennzeichnet sind. Breiter Wettbewerb und gesättigte Märkte erfordern von Unternehmen heute eine schnelle Reaktion, um erfolgreich zu sein. Gesellschaftliche, politische und umweltspezifische Veränderungen führen dazu, dass sich Bedürfnisse rapide ändern und Produktlebenszyklen kürzer werden, es sei denn, man kann schnell darauf reagieren.

Daher ist es legitim, dass Startups und junge Unternehmen mit agilen Methoden und Werten auch in streng regulierte Bereiche vordringen und versuchen, innovativ und unternehmerisch zu sein. Dennoch gelten für sie die gleichen Anforderungen an Regulierung und Qualität wie für etablierte Organisationen, die traditionelle Wege gehen. Startups müssen sich und ihre Softwareentwickler*innen professionalisieren, um dem entgegenzuwirken und sich erfolgreich auf dem regulierten Markt behaupten zu können.

In diesem Kontext unterstützt der AgileTrio Ansatz mit einem eingebetteten regulierten Framework. Das Framework stellt Leitlinien bereit, die dem Entwicklungsteam den richtigen Weg zeigen sollen, um schnell, aber gleichzeitig nutzerzentrierte und hochwertige Softwareprodukte liefern zu können.

2. Klassisches Vorgehen

Ich habe meine Karriere um das Jahr 2000 in einem mittelständischen Unternehmen für Medizinprodukte im Bereich minimalinvasive Chirurgie begonnen. Dieses Unternehmen war zum damaligen Zeitpunkt bereits weltweit führend auf diesem Gebiet. Es wurde von der einzigen Tochter des Gründers matriarchalisch geführt und hatte den Ruf, familiär und traditionell zu sein. Alle Entscheidungen wurden ausschließlich von der Geschäftsführerin getroffen, selbst wenn dies bedeutete, dass man Monate auf einen neuen Bürostuhl warten musste. Es gab eine strenge Hierarchie, viel Unternehmenspolitik und alles lief über Beziehungen. Jeder kannte seinen Platz.

Ich war damals 16 Jahre alt und hatte wenig Berufserfahrung. Wahrscheinlich war es positiv für mich, dass die Geschäftsführerin sich wie eine Mutter einer großen Familie um die Belegschaft kümmerte. Ich blieb dort zehn Jahre, absolvierte meine Ausbildung sowie meine erste Fortbildung und entdeckte meine Begeisterung für die Entwicklung von hardwarenaher Software. Während meiner Zeit dort hat das Unternehmen seine Mitarbeiterzahl und seinen Umsatz verdoppelt.

Mikrocontroller, Embedded Systeme und Field Programmable Gate Arrays als Teil von Produkten und damit auch Software begannen sich zu diesem Zeitpunkt zu etablieren. Eigentlich waren diese Technologien damals bereits etwa zehn Jahre alt, aber in der Medizintechnik konnte man bezüglich der technologischen Entwicklung nicht mithalten. Neue Technologien müssen sich erst als sicher und zuverlässig erweisen, bevor sie in der Medizintechnik eingesetzt werden können. Forschung und Entwicklung sind häufig strikt voneinander getrennt. Wenn Technologien in die Entwicklung einbezogen werden, sind sie in der Regel gut erforscht und ausgereift. Der Schwerpunkt liegt in der Entwicklung darauf, eine stabile Reproduzierbarkeit von Produkten zu erreichen, um später eine gute und sichere Produktion gewährleisten zu können.

Solche Unternehmen sind oft stark technologieorientiert und berücksichtigen nicht immer die Bedürfnisse und Probleme der Nutzenden in ihren Entscheidungen. Produktentwicklungen dauern in der Regel drei bis fünf Jahre und spiegeln meist inkrementelle Innovationen wider. So werden bekannte Klinische Anwendungen mit anderer existierender Technologie versorgt. Dies wird oft durch Bauteilabkündigungen verursacht, die sich nicht leicht kompensieren lassen. Alternativ wird die gleiche Technologie für ähnliche oder alternative Klinische Anwendungen verwendet. Auch hier vorzugsweise inkrementell, da die Klinische Anwendung meist schon bekannt ist, aber alternativ eingesetzt wird.

Es wird demnach ein konservatives oder ausbalanciertes Wachstumsportfolio angestrebt. Dieses folgt dem 70-20-10 Modell von Eric Schmidt und Sergey Brin [2]. Dabei gehen 70% der Ressourcen in inkrementelle Innovationen, 20% in neue Märkte für das Unternehmen oder aktuellere Technologie für bestehende Märkte und 10% in die Forschung. Somit ergeben sich für regulierte Märkte wie der Medizintechnik feste Rahmenbedingungen und eine stabile Umgebung, was ideal für klassisches Projektmanagement ist.

Das Denken in Projekten

Ein Projekt zielt darauf ab, von einem bestehenden Zustand zu einem neuen Zustand zu gelangen. Dabei kann der bestehende Zustand entweder bereits ein Produkt sein, das im neuen Zustand verbessert werden soll, oder es handelt sich um eine Produktidee. Der neue Zustand ist das entwickelte Produkt, das die Bedürfnisse der Nutzenden erfüllen oder ihre Probleme lösen soll.

Das Projektmanagement umfasst verschiedene Aufgaben, die zur Führung gehören und von speziellen Projektmanagern*innen übernommen werden. In einer Matrixstruktur liegt die fachliche Führung normalerweise bei den Projektmanagern*innen. Wenn das Unternehmen jedoch in Projektteams unterteilt ist, kann es sein, dass die Projektmanager*innen zusätzlich die disziplinare Führung ihrer Teams übernehmen.

Das Projektmanagement beinhaltet die Initiierung, Planung, Steuerung, Organisation, Durchführung, Kontrolle und den Abschluss von Projekten. Es ist ein wichtiger Bestandteil der Arbeitsorganisation in vielen Unternehmen, um die besten Ergebnisse in einer komplexen und globalen Arbeitsumgebung zu erzielen. Es schafft Struktur, klärt Ressourcen, definiert Schnittstellen und Vorgehensweisen.

Initiierung – Die Initiierung eines Projektes verwandelt eine vage Idee in einen verbindlichen Projektauftrag. Dabei werden üblicherweise Fragen zur Ressourcenplanung, Meilensteinen und Rentabilität geklärt. Es ist wichtig zu prüfen, ob das Projekt mit den vorhandenen Ressourcen umgesetzt werden kann und ob es zur Strategie und Wirtschaftlichkeit der Organisation passt. Projekte innerhalb einer Organisation konkurrieren ständig um begrenzte Ressourcen. Aus diesem Grund haben viele Organisationen ein Projektportfolio, in dem Projekte miteinander verglichen werden. Es wird zudem überlegt und festgelegt, welche Aufgaben mit internen Ressourcen bewältigt werden können und welche Projekte oder Projektteile externe Unterstützung benötigen. Das Ergebnis dieser Initiierung ist normalerweise ein Projektvertrag.

Planung – Die Planung von komplexen Projekten umfasst den Einsatz von Ressourcen, die Festlegung des Ablaufs, der Termine und der Projektkosten. Außerdem werden die Ziele in überschaubare Arbeitspakete aufgeteilt. Es wird überprüft, ob die Vorgaben des Auftraggebenden realistisch sind. Um die Abhängigkeiten zwischen den drei Hauptfaktoren Kosten, Zeit und Ergebnisse zu verdeutlichen, wird das magische Dreieck verwendet:

Die drei Faktoren - Qualität der Ergebnisse und Funktionalität, Zeit und Kosten - sind untrennbar miteinander verbunden. Eine Veränderung eines Faktors wirkt sich zwangsläufig auf die anderen beiden aus. Es ergeben sich unterschiedliche Projektstrategien, je nachdem, welcher Faktor priorisiert wird:

• Best-to-Market: Hier steht die Qualität der Ergebnisse und Funktionalität im Vordergrund. Ziel ist es, am Markt neue Kunden*innen besonders gut anzusprechen.

• Time-to-Market: Hier liegt der Fokus auf der Zeit. Das Ziel ist es, so schnell wie möglich am Markt präsent zu sein und dadurch die Konkurrenz zu überholen.

• Design-to-Cost: Hier stehen die Kosten im Mittelpunkt. Das Ziel ist es, die Kosten bis zum Markteintritt zu reduzieren, sei es durch Materialkosten oder Produktionskosten, um am Markt profitabler zu sein.

Oftmals scheitert das Projekt bereits an diesem Punkt, da Auftraggebende oder Stakeholder am liebsten in allen drei Bereichen erfolgreich sein möchten. Das Ergebnis dieser Planung ist ein konkreter Projektplan.

Steuerung – Die Projektleitung nutzt die Zahlen und Berichte des Controllings, um das Projekt zu steuern. Dabei müssen Anpassungen basierend auf Kennzahlen zu Kosten, Qualität, Ressourcen, Kommunikation, Risikomanagement, Beschaffung, Stakeholder-Erwartungen sowie Projektzielen und -umfang vorgenommen werden. Es kommt häufig vor, dass Projekte nicht wie geplant verlaufen. Ressourcen stehen nicht rechtzeitig zur Verfügung, Lösungen funktionieren nicht wie erwartet, Mitarbeitende sind nicht uneingeschränkt verfügbar, die Erwartungen der Stakeholder ändern sich und das Projektumfeld ist im ständigen Wandel. Die Steuerung des Projekts befasst sich mit den erforderlichen Anpassungen.

Organisation – Die Organisation von Projekten befasst sich mit den Rahmenbedingungen der Organisation. Dabei geht es um die Verantwortung der Projektführung, Entscheidungsbefugnisse, erforderliche Fachkenntnisse, interne Kommunikation im Projekt und die Kommunikation mit externen Interessengruppen sowie die Verfügbarkeit von Ressourcen. Oftmals treffen hier die Matrixstruktur und die Projektumgebung aufeinander. Das bedeutet, dass Projektmitarbeitende häufig nicht ausschließlich dem Projekt gewidmet sind, sondern auch noch Aufgaben innerhalb der Organisationsstruktur erledigen müssen. Es kann auch vorkommen, dass Projektmitarbeitende noch für weitere Projekte zuständig sind, die sie ebenfalls betreuen müssen. Konflikte treten in einer schwach organisierten Projektstruktur häufig auf.

Durchführung – Die Durchführung eines Projekts umfasst das Umsetzen der Projektpläne mit den vorhandenen Ressourcen, innerhalb der vereinbarten Kosten und innerhalb der zuvor festgelegten Zeit. Dabei müssen verbindliche Ergebnisse erzielt werden. Es ist wichtig, Abhängigkeiten und Engpässe zu berücksichtigen und entsprechend damit umzugehen. In klassischen Organisationen, insbesondere im regulierten Umfeld, wird die Durchführung oft nach dem V-Modell in Kombination mit dem Stage-Gate-Ansatz durchgeführt. Es gibt aber auch andere Vorgehensweisen zur Durchführung, die gewählt werden können.

Kontrolle – Die Kontrolle sorgt dafür, dass die Projektziele erreicht werden. Sie beginnt bereits bei der Initiierung, indem Projekte im Portfolio priorisiert werden. Während der Durchführung werden Kennzahlen verwendet, um kontinuierlich Zeit, Kosten und Qualität des Projekts zu überprüfen und sicherzustellen, dass die Ziele erreicht werden können. Dafür werden verschiedene Berichte erstellt, die sowohl den Stakeholdern als auch dem Projektteam den aktuellen Stand des Projekts zeigen. Diese Berichte ermöglichen es, Entscheidungen zu treffen und bei Bedarf einzugreifen, um das Projekt zu lenken.

Abschluss – Ein Projektabschluss beginnt normalerweise mit einer Übergabe. Die Übergabe kann an die Fertigung, einen neuen Besitzenden, IT-Operations oder einen anderen Stakeholder erfolgen. Häufig sind damit Abnahmeinspektionen, Schulungen oder Inbetriebnahmen verbunden. Diese Übertragung oder der Transfer ist ein kritischer Schritt, bei dem Ergebnisse weitergegeben werden. Da sich das Projektteam in der Regel nach Abschluss auflöst, ist es für den Empfangenden oft schwierig, nachträgliche Korrekturen zu erhalten. Das Projektteam muss auch darauf achten, dass berechtigte Nachforderungen gestellt werden und nicht zu übertriebenen Forderungen führen. Im Projektmanagement ist es zudem ratsam, eine Retrospektive durchzuführen, um aus dem Projektablauf zu lernen und Erfahrungen in zukünftige Projekte einfließen zu lassen.

Projektarbeit in Matrix- oder Linienstrukturen kann für Mitarbeitende eine willkommene Abwechslung im täglichen Geschäft bieten. In solchen Organisationen beschränkt sich die Rolle der Mitarbeitenden oft nur auf ihre Aufgaben innerhalb von Prozessen, während die Mitarbeit an Projekten mehr Vielfalt ermöglicht. Es fördert die Zusammenarbeit mit anderen Abteilungen und erweitert den Horizont. Durch zielgerichtetes Arbeiten kann man den Fortschritt innerhalb eines Projektes besser verfolgen und nachvollziehen. Die individuellen Beiträge der Teammitglieder sind dabei oft deutlicher erkennbar als im Alltagsgeschäft. Es kann sehr motivierend sein, einen Unterschied zu machen.

Ein weiterer großer Vorteil des Projektmanagements besteht darin, dass es Struktur und Ordnung schafft. Insbesondere bei komplexen Projekten mit vielen externen Schnittstellen und Abhängigkeiten ist eine sorgfältige und vorausschauende Planung wichtig, um Engpässe und lange Wartezeiten zu vermeiden. Projektmanagement bietet einen effektiven und robusten Ansatz, um gewünschte Ergebnisse zu erzielen, insbesondere für strenger regulierte Produkte mit klar definierten Vorgaben und stabilem Umfeld. Wenn die Vorgaben unklar sind und das Umfeld instabil ist, geraten Projekte oft an ihre Grenzen. In solchen Fällen funktionieren agile Ansätze meist besser, wie später im Kapitel Agiles Vorgehen erläutert wird.

Für diejenigen, die mehr über Projektmanagement erfahren möchten, empfehle ich das Buch „Handbuch Projektmanagement - Agil - Klassisch - Hybrid" [3]. Ich stehe dem Thema agiles Projektmanagement kritisch gegenüber. Im Kapitel Agiles Vorgehen wird darauf hingewiesen, dass ich im agilen Ansatz bevorzugt von Produkten statt von Projekten spreche. Trotzdem empfehle ich definitiv, das Buch anzuschauen.

V-Model

Ich habe das V-Modell aus den klassischen Vorgehensmodellen für Entwicklungsprojekte ausgewählt. Es ist das häufigste Modell in regulierten Umgebungen und eignet sich besonders gut für die Entwicklung von physischen Medizinprodukten. Im agilen Umfeld wird oft behauptet, dass das V-Modell nichts anderes als ein Wasserfallmodell sei. In diesen Kreisen wird alles außerhalb agilen Vorgehens als Wasserfallmodell bezeichnet. Ich halte das für sehr undifferenziert und es ist meistens ein Anzeichen dafür, dass man stark vom agilen Ansatz überzeugt ist. Menschen mit dieser Einstellung beschränken sich bewusst in ihren Möglichkeiten, Produkte zu entwickeln. Das V-Modell ermöglicht, in Kombination mit dem Stage-Gate-Ansatz, moderate Iterationen. Ein Wasserfallmodell hingegen ermöglicht das nicht.

Das V-Modell besteht aus drei Hauptphasen: Spezifikation, Implementierung und Test. In der Spezifikationsphase werden die Anforderungen festgelegt und in der Implementierungsphase wird die Software entwickelt. Die Testphase dient der Überprüfung der Funktionalität. Das V-Modell wurde ursprünglich im Jahr 1979 von Barry Boehm entwickelt [4]. Es wurde jedoch erst um die Jahrtausendwende weitgehend anerkannt und fand Eingang in viele Standards und Normen als repräsentatives Modell. Ein Beispiel dafür ist der Standard EN IEC 62304 [5], der das V-Modell als Grundlage verwendet. Es ist jedoch wichtig zu beachten, dass der Standard nicht zwingend die Verwendung dieses Modells vorschreibt.

Spezifikationsphase – Während der Spezifikationsphase werden Nutzeranforderungen erfasst und definiert. Technische Anforderungen werden in unterschiedlicher Detailtiefe spezifiziert, abhängig von der Komplexität der Entwicklung. Diese umfassen Systemanforderungen, Software-/Hardware-/Mechanische Anforderungen, Komponentenanforderungen, Einheitenanforderungen sowie detailliertes Design und Architektur. Das Produkt wird dabei schrittweise in seine Bestandteile zerlegt und diese werden spezifiziert. Die Tiefe und Detailgenauigkeit der Spezifikation hängen oft von der Komplexität und dem Risiko, das vom Produkt ausgehen kann, ab. Insbesondere im streng regulierten Umfeld steht die Betriebssicherheit im Vordergrund. Bei Flugzeugen, Autos, Kraftwerken, elektrischen Geräten oder Medizinprodukten ist es unabdingbar, sorgfältig zu prüfen, welche Aspekte berücksichtigt werden müssen. Eine nachlässige oder ungenaue Spezifikation kann oft zu unnötigen Risiken für Endanwendende oder die Umwelt führen.

Implementierungsphase – In der Implementierungsphase werden die Anforderungen umgesetzt. Dabei wird die Funktionalität entsprechend in Hardware, Software oder Mechanik implementiert. Es ist wichtig, darauf zu achten, dass alles später zusammenpasst. Dafür werden oft genaue Schnittstellen spezifiziert, an die sich alle halten müssen. So können auch sehr große und komplexe Projekte mit vielen Teammitgliedern, verschiedenen Disziplinen und Fachwissen, die auf interne Mitarbeitende und externe Partner*innen verteilt sind, umgesetzt werden.

Testphase – Während der Testphase werden die entsprechenden Testfälle durchgeführt. Diese werden oft gleichzeitig mit der Spezifikation erstellt. Die Verifizierung beginnt mit den Einheitentests und geht dann über Komponententests, Integrationstests und Systemtests zur Validierung. Man erreicht erst dann die nächste Stufe, wenn die Testergebnisse positiv und akzeptabel sind. Wenn Probleme auftreten, kehrt man zur Spezifikationsphase zurück und iteriert moderat. Das Ziel besteht darin, alle Anforderungen aus der Spezifikationsphase durch positive Testfälle zu bestätigen. Test Driven Development kann hier genutzt werden. Es wird allerdings nicht sofort gegen die Testfälle implementiert. Bei Test Driven Development werden die Testfälle und die Spezifikation der Anforderungen gleichzeitig formuliert. Mehr zu dieser Technik im Kapitel Verifizierung. Folgende Grafik stellt das V-Modell dar:

Das V-Modell unterscheidet sich deutlich vom Wasserfallmodell. Im V-Modell werden Testfälle normalerweise gleichzeitig mit der Spezifikation erstellt. Für den Fall, dass während der Testphase etwas schiefgeht, werden Tests auf höherer Ebene nicht fortgesetzt. Stattdessen wird ein Schritt zurück zur Spezifikationsphase gemacht, um das Problem zu lösen. Dadurch ergeben sich Möglichkeiten, das Produkt durch moderate Iterationen anzupassen.

Ich persönlich habe das Entwickeln nach dem V-Modell insbesondere in Luftfahrtprojekten im streng regulierten Umfeld kennengelernt. Bei der Mitentwicklung eines Flugzeugs gibt es wenig Spielraum für Experimente und Lernen aus Fehlern. Es arbeiten viele Organisationen und Teams an einem komplexen System zusammen. Die Anforderungen an einzelne Flugzeugkomponenten müssen sehr detailliert und umfassend definiert werden. Die Implementierung muss den Anforderungen entsprechen und funktionieren. Wenn dies nicht der Fall ist, passt die entwickelte Komponente nicht zu den anderen Komponenten im Flugzeug. Wenn eine Komponente nicht zuverlässig funktioniert, kann dies im schlimmsten Fall die Sicherheit des Flugzeugs und die Menschen gefährden.

Der A350 von Airbus fliegt seit 2015. Bis heute wurden etwas mehr als 500 Stück ausgeliefert. Etwas mehr als 400 weitere sind in Auftrag gegeben worden. 37 gemeldete Zwischenfälle sind bis Anfang 2023 bekannt geworden. Keiner der Vorfälle führte zu Abstürzen oder Unfällen mit Todesopfern.

Das Entwickeln nach dem V-Modell in Projekten kann demnach Produkte ermöglichen, bei denen zahlreiche Organisationen an einem komplizierten System zusammenarbeiten und es zum Schluss bei der Nutzung des Produktes, kein Spielraum für Fehler gibt.

Moderate Iterationen durch Stage-Gate

Einen richtigen Schub bekommt das V-Modell durch Robert G. Coopers Stage-Gate Phasenmodell [6]. Cooper hat das Modell im Laufe der Zeit weiterentwickelt. Das Stage-Gate Phasenmodell zeigt fünf Phasen für die Produktentstehung auf. Jeder Übergang von einer Phase zur nächsten erfolgt über ein Gate, das passiert werden muss. Das V-Modell wird innerhalb der Phasen immer wieder durchlaufen, jedoch mit unterschiedlicher Gewichtung von Produktmanagement und Entwicklung. Dies gilt auch innerhalb der Entwicklung selbst, speziell in der Spezifikationsphase, Implementierungsphase und Testphase. Die Gates dienen als konkrete Design Reviews, wie sie oft in regulierten Umgebungen gefordert werden. Folgendes Bild zeigt den Ablauf des Stage-Gate Phasenmodells:

Hier sind in den einzelnen Stages und Gates folgende Schwerpunkte vorgesehen:

• Stage 1 – Ideenfindung: Bei der Ideenfindung werden Nutzerbedürfnisse und Probleme erkannt, analysiert und mit der Unternehmensstrategie abgeglichen. Darauf basierend werden Ideen generiert, angereichert, bewertet und es werden vielversprechende Ideen weiterverfolgt.

• Gate 1 – Ideenprüfung: In der Ideenprüfung werden Ideen grob anhand von Kosten-Nutzen-Überlegungen und begrenzten Ressourcen ausgewählt. Anhand detaillierter Kennzahlen wird dann entschieden, ob diese Ideen umgesetzt werden sollen. Die Entscheidung basiert auf Zahlen, Daten und Fakten, nicht auf Bauchgefühl. Die Auswahlkriterien müssen transparent sein.

• Stage 2 – Konzept: In der Konzeptphase werden detaillierte Nutzeranforderungen festgelegt. Diese werden mit den Nutzenden an Modellen oder Prototypen bewertet und die technische Machbarkeit geprüft. Es werden auch rechtliche und regulatorische Anforderungen identifiziert und ein konkreter Businessplan erstellt, der die Wirtschaftlichkeit, Absatzplanung und Prognosen berücksichtigt.

• Gate 2 – Entwicklungsfreigabe: Bei der Entwicklungsfreigabe wird überprüft, ob alle Nutzeranforderungen erfasst worden sind und diese bestimmte Qualitätskriterien erfüllen. Es wird auch die technische Machbarkeit und wirtschaftliche Umsetzbarkeit bewertet. Es wird geprüft, ob ein ausgereifter Businessplan inklusive Finanzplanung vorhanden ist.

• Stage 3 – Entwicklung: In der Entwicklungsphase wird das Konzept zur Marktreife gebracht. Es werden konkrete technische Anforderungen erstellt, verschiedene Varianten und Designs diskutiert und Entscheidungen getroffen. Es werden erste Prototypen hergestellt und die Produktionsplanung oder IT-Operations-Infrastruktur vorbereitet.

• Gate 3 – Testfreigabe: Für die Testfreigabe werden das technische Design und dessen Dokumentation auf Qualitätskriterien überprüft. Die Prototypen müssen einen gewissen Reifegrad erreicht haben und die Testpläne für Verifizierung und Validierung müssen ausgereift sein. Es müssen erste Lieferanten evaluiert werden, um vollständige Prototypen zu erstellen oder eine IT-Operations-Infrastruktur aufzubauen.

• Stage 4 – Verifizierung & Validierung: In der Verifizierungs- und Validierungsphase wird das Produkt auf technische Korrektheit überprüft und zusammen mit den Nutzenden auf Tauglichkeit validiert. Dies geschieht in verschiedenen Testläufen. Der Marketingplan wird abgeschlossen und der Vertrieb sowie die Produktion oder finale IT-Operations werden vorbereitet.

• Gate 4 – Freigabe der Einführung: Vor der Freigabe der Einführung werden die Ergebnisse der Verifizierung und Validierung überprüft. Die ausgewählten Lieferanten werden bewertet. Es wird evaluiert, ob regulatorische und gesetzliche Vorschriften eingehalten werden. Die Pläne für Marketing und Vertrieb werden gesichtet. Zudem wird die Qualität und Vollständigkeit der Pläne und Umsetzung für den Designtransfer in die Produktion oder IT-Operations-Infrastruktur begutachtet.

• Stage 5 – Produktion & Markteinführung: In der Produktion und Markteinführung wird die Qualitätsüberwachung finalisiert. Es werden Service-, Wartungs- und andere produktbegleitende Dienstleistungen eingerichtet. Die Marketing- und Vertriebsmaterialien werden fertiggestellt und das Personal wird geschult. Es wird eine abschließende Wirtschaftlichkeitsanalyse für den gesamten Produktlebenszyklus durchgeführt. Das Produkt wird registriert und schließlich auf den Markt gebracht.

Wenn ein Gate nicht passiert wird, weil die vorangegangene Phase nicht die erwarteten Ergebnisse liefert, hat der Auftraggebende zwei Möglichkeiten: entweder das Projekt abzubrechen oder das Entwicklungsteam durchläuft eine weitere Iteration der vorangegangenen Phase. Dadurch wird eine bessere Kontrolle der Kosten und des Nutzens im Vergleich zum einfachen V-Modell erreicht.

In jeder Phase des Stage-Gate Phasenmodells werden verschiedene Schwerpunkte gesetzt, wie Produktvision, Nutzeranforderungen, technische Anforderungen an Systeme, Software, Hardware oder Mechanik, Implementierung, Verifizierung und Validierung sowie Produktüberleitung. Diese Schwerpunkte haben unterschiedliche Ausprägungen in den einzelnen Phasen. Zu Beginn stehen Produktvision und Nutzeranforderungen im Fokus, in den mittleren Phasen liegen die technischen Anforderungen sowie Implementierung und Verifizierung im Vordergrund, und am Ende stehen Validierung und Produktüberleitung.

Das bedeutet jedoch nicht, dass in den moderaten Iterationen in der letzten Phase keine Anpassungen an Nutzeranforderungen oder sogar der Produktvision vorgenommen werden können. Zwar sollten in der letzten Phase keine großen Änderungen mehr umgesetzt werden, aber kleinere Anpassungen sind immer noch möglich.

Das folgende Bild zeigt eine mögliche Gewichtung der Fokusthemen über die Phasen des Stage-Gate Phasenmodells:

Die Kombination des V-Modells mit dem Stage-Gate Phasenmodell begünstigt infolgedessen moderate Iterationen in der Produktentstehung. Die Produktentstehung erfolgt dabei als Projekt. Das sorgt für eine gute Balance an Änderungsmöglichkeit und Stabilität, die besonders in einem regulierten Umfeld mit vielen Kontrollmechanismen oft einem optimalen Vorgehen entspricht. Aus diesem Grund ist dieser Ansatz das gängigste Vorgehen im regulierten Umfeld und erlaubt komplizierte Produkte entwickeln zu können.

Mehr zum Thema chaotische, komplexe, komplizierte und einfache Situationen, erklärt am Cynefin-Framework, im Kapitel Agiles Vorgehen. Komplexe Vorhaben werden durch das Vorgehen über die einzelnen Stages zu komplizierten Vorhaben heruntergebrochen. Ursache und Wirkung sollten bei jedem streng regulierten Produkt spätestens vor Markteinführung bekannt sein.

Neue und innovative Ansätze werden dagegen oft entkoppelt und als Forschung separat abgehandelt. Das wiederum erklärt das Phänomen, das beispielsweise in der Medizintechnik oft Technologie eingesetzt wird, die bereits acht bis zehn Jahre zuvor ihren Durchbruch hatte.

Es ist wichtig anzumerken, dass das hier beschriebene V-Modell und Stage-Gate Phasenmodell nur beispielhaft ist. Jede Organisation muss ihr eigenes spezifisches V-Modell und Stage-Gate Phasenmodell definieren, das zu ihren Produkten, ihrem Umfeld, ihrer Strategie, ihrer Organisationsstruktur und ihren Mitarbeitenden passt. Die Tiefe des V-Modells kann je nach Kritikalität und Komplexität des Produkts oder Systems variieren. Der untere Teil des V-Modells kann auch in separate V-Modelle für verschiedene Disziplinen wie Mechanik, Hardware und Software aufgeteilt werden. Es ist demnach wichtig, das Vorgehen an die individuellen Gegebenheiten anzupassen.

3. Klassisches Mindset

Während ich bei meiner Arbeitsweise gerne sowohl klassisches als auch agiles Vorgehen verwende und dabei angepasst an das Problem verfahre, kann ich das vom klassischen Mindset nicht behaupten. Ich gehöre der Generation Y an und wie bei vielen jungen Menschen meiner Generation sind Konkurrenz- und Bürokratiewerte nicht so stark ausgeprägt, wie bei den Generationen davor. Ich erinnere mich an eine Situation bei meinem ersten Arbeitgeber, in der ich mit meinem Vorgesetzten eine Diskussion über meine hohe Vergütung hatte. Aus meiner Sicht wäre es Verschwendung gewesen lediglich meine Hände zum Arbeiten zu benutzen, wenn ich dem Unternehmen zusätzlich durch meine Denkfähigkeit mehr Nutzen hätte bringen können. Ich war damals im technischen Service tätig und habe elektrische Medizinprodukte repariert.

Bereits in jungen Jahren war es mir wichtig, mich beruflich aktiv einzubringen und Entscheidungen selbst zu treffen. Das einfache Befolgen von Anweisungen entsprach nicht meiner Vorstellung von sinnvoller Arbeit. Im Regelfall benötige ich keinen Vorgesetzten, um adäquate Entscheidungen zu treffen. Außerdem neige ich dazu, improvisieren zu wollen, anstatt mich streng an Vorgaben und Prozesse zu halten.

Meine Konsenswerte sind weniger stark ausgeprägt. Das führe ich auf die Tatsache zurück, dass ich mit einer großen Anzahl von Geschwistern aufgewachsen bin. Dafür sind meine Entrepreneurwerte stärker ausgeprägt, was dazu führen kann, dass ich dem Vorgesetzten gegenüber betone, dass meine Loyalität der Organisation gilt und nicht lediglich ihm.

Das zeigt, dass jeder Mensch oder auch Arbeitnehmende eigene Bedürfnisse hat. Früher wurde dies mithilfe der Maslowschen Bedürfnispyramide erklärt. Doch wie nahezu jedes Forschungsgebiet hat auch die Neuropsychologie Fortschritte gemacht. Heute verwenden wir den Spiral Dynamics Ansatz von Don Beck und Chris Cowan [7]. Richard Barrett hat daraus das „Barrett Modell" entwickelt, das 2011 [8] veröffentlicht wurde und heute oft für Persönlichkeits- und Führungskräfteentwicklung genutzt wird. Das Modell beschreibt sieben Bewusstseinsebenen:

1. Lebensfähigkeit – Befriedigung unserer körperlichen Bedürfnisse und Überlebensbedürfnisse Angst: Ich habe nicht genug

2. Beziehungen – Sich beschützt und geliebt fühlen.

Angst: Ich werde nicht genug geliebt

3. Leistung – Gefühl des Selbstwertgefühls

Angst: Ich bin nicht genug

4. Evolution – Ängste loslassen. Den Mut, sich weiterzuentwickeln und zu wachsen

5. Ausrichtung – Sinn in der Existenz finden

6. Zusammenarbeit – Einen positiven Unterschied in der Welt bewirken

7. Beitrag – Selbstloser Dienst

Richard Barrett hat die sieben Ebenen in drei Bereiche unterteilt.

Der Bereich der ersten drei Ebenen – Lebensfähigkeit, Beziehungen und Leistung – betonen unser persönliches Interesse. Sie beinhalten das Erfüllen unserer Bedürfnisse nach Sicherheit, Liebe und Zugehörigkeit sowie das Streben nach Stolz und Zufriedenheit mit uns selbst. Wenn diese Bedürfnisse erfüllt sind, fühlen wir uns nicht dauerhaft befriedigt, aber wir empfinden Ängste, wenn sie nicht erfüllt werden.

Im Bereich der vierten Ebene – Evolution – liegt der Fokus auf dem Loslassen von Ängsten. Hier entwickeln wir ein Bewusstsein für unsere persönliche Autorität und unsere eigene Stimme. In dieser Phase entscheiden wir uns dafür, nach unseren innersten Werten und Überzeugungen zu leben.

Der Bereich der oberen drei Ebenen – Ausrichtung, Zusammenarbeit und Beitrag – konzentriert sich auf unser Bedürfnis, Sinn und Zweck in unserem Leben zu finden. Wir drücken diese Bedeutung aus, indem wir danach streben, unsere Welt zu verbessern und selbstlos zu dienen. Wenn diese Bedürfnisse erfüllt sind, entsteht eine tiefere Motivation und Hingabe. In diesen Bereichen lernen wir, unseren inneren Kompass zu entwickeln, der uns dabei hilft, positive Entscheidungen zu treffen, die das Leben bejahen.

Richard Barrett stellt fest, dass Menschen, die ausschließlich ihre persönlichen Grundbedürfnisse im Blick haben, von Ängsten beeinflusst werden können und nach Zustimmung oder Bestätigung anderer suchen. Wenn sich Menschen ausschließlich auf die Erfüllung des dritten Bereichs konzentrieren, fehlen ihnen möglicherweise die Fähigkeiten, um praktisch und effektiv zu handeln, wenn es um ihre Grundbedürfnisse geht. Die erfolgreichsten Menschen, so Barett sind diejenigen, die alle sieben Ebenen miteinander in Einklang bringen. Sie vertrauen anderen, können mit Komplexität umgehen und sich an unterschiedliche Situationen anpassen.

Laut Richard Barrett operieren Menschen jedoch nicht nur auf einer einzigen Bewusstseinsebene. In der Regel konzentrieren sie sich auf drei oder vier Ebenen. Gewöhnlich richten sich Individuen auf die Ebenen eins bis fünf aus und legen dabei besonderes Augenmerk auf die Suche nach dem Sinn des Lebens in der fünften Ebene.

Wenn man die gesellschaftliche Verteilung basierend auf persönlichen Werteeinschätzungen betrachtet, stellt man fest, dass etwa 50% der Menschen ihre Werte auf die ersten drei Ebenen ausrichten. Weitere 30% fokussieren sich auf die vierte Ebene, was Selbstreflexion und den Mut beinhaltet, sich den eigenen Ängsten zu stellen und an sich zu arbeiten. Die letzten 20% legen ihren Schwerpunkt auf die Werte des dritten Bereichs.

Der Wunsch nach Sicherheit, Ordnung, Zugehörigkeit und persönlichem Eigeninteresse ist demnach in der Gesellschaft weit verbreitet und erklärt auch die starke Prävalenz konservativer und klassischer Denkmuster. Traditionelle Managementmodelle und starke Hierarchien unterstützen und spiegeln diese Werte bevorzugt wider.

Managementmodelle

Um zu verstehen, warum das klassische Mindset immer noch so dominant ist, ist es hilfreich, sich mit den Managementmodellen von Alfred Oswald [9] auseinanderzusetzen. Organisationen unterliegen im Laufe der Zeit Veränderungen, die durch sich wandelnde Geschäftsfelder, -modelle und neue Technologien vorangetrieben werden. Neue Geschäftsmodelle, die besser auf die Bedürfnisse von Nutzenden und Kunden*innen eingehen oder ressourcenschonender sind, zerstören alte Geschäftsmodelle und manchmal auch ganze Organisationen, wenn sie nicht selbst innovativ sind. Mit neuen Geschäftsmodellen ändert sich oft auch die interne Struktur. Verantwortlichkeiten werden neu verteilt, Entscheidungsbereiche verlieren an Einfluss, während andere an Bedeutung gewinnen. Mitarbeitende wechseln dann entweder weiter zu anderen Organisationen oder werden Teil neuer Strukturen.

Ein weiterer großer Einflussfaktor, der Organisationen verändert, ist der soziologische Aspekt. Unterschiedliche Generationen haben unterschiedliche Wertvorstellungen. Jede Generation wird von der Zeit geprägt, in der sie aufwächst. Seit 1922 gibt es sechs verschiedene Generationen, die sich wie im Bild gezeigt aufteilen:

Entsprechend der Wertevorstellungen der einzelnen Generationen, ist auch das darauffolgende Arbeitsleben und die Art des Arbeitens geprägt. Daraus ergeben sich aktuell drei Modelle des Managements:

• Management 1.0 – geprägt durch Industrialisierung und Taylorismus: Dieses Management-Modell basiert auf dem Taylorismus und ist klassisch und etabliert. Die Arbeit wird in Prozessschritte aufgeteilt, wobei jeder Mitarbeitende für einen Schritt verantwortlich ist. Es gibt eine klare Hierarchie im Management, bei der Ziele, Entscheidungen und Verantwortung von oben nach unten weitergegeben werden. Hierarchie und Arbeitsteilung bieten den Mitarbeitenden einen Rahmen, innerhalb dessen sie handeln können.

Das Top-Management kümmert sich um die strategische Ausrichtung des Unternehmens. Das Management in den unteren Ebenen ist für die Umsetzung der Strategie zuständig, indem es Prozessschritte festlegt, und die benötigten Ressourcen, Zeit und Mitarbeitenden plant. Die Unternehmensziele sind klar definiert und alle kennen ihren Platz und ihre Aufgaben. Dies kann den Mitarbeitenden ein Gefühl von Sicherheit und Stabilität vermitteln.

Die Überwachung und Kontrolle stellen sicher, dass die Unternehmensziele und die Qualität erreicht werden. Das Management kann Anpassungen und Korrekturen vornehmen. Die Verantwortung wird nach oben weitergegeben, sodass letztendlich das Top-Management oder die Geschäftsführenden die volle Verantwortung tragen.

Dieses Modell ist skalierbar und eignet sich daher für Unternehmen jeder Größe. Es wird häufig von großen traditionellen Unternehmen oder Behörden genutzt.

• Management 2.0 – geprägt durch Balanced Scorecards und Total Quality Management: In diesem Modell steht der Fokus auf den Mitarbeitenden als Humanressourcen in den organisatorischen Prozessen. Ziel ist es, sie durch Motivationsanreize zu besseren Leistungen zu bewegen. Dabei spielen extrinsische und intrinsische Motivationsfaktoren eine Rolle. Bei extrinsischer Motivation geht es um Gehalt, Boni, Status, Geschäftswagen, Bürogröße oder Titel. Intrinsische Motivation wird durch individuelle Ziele angestrebt, die den Mitarbeitenden helfen, ihren Beitrag zu den strategischen Zielen der Organisation transparenter zu erkennen.

Alle schwergewichtigen Managementsysteme und große Teile der regulatorischen Anforderungen, setzen dieses Management Modell voraus. Methoden wie Projektmanagement, Balanced Scorecards und auch das V-Modell kommen hier bevorzugt zum Einsatz. Durch Management by Objectives bleibt es aber bei holistischen Zielen, die vom Top-Management auf alle individuell herunter gebrochen werden. Mehr dazu später in diesem Kapitel.

Die Unternehmensstruktur ist hierarchisch aufgebaut, mit einem Top-Management und mehreren Führungsebenen darunter. Die Führungskultur ist top-down orientiert, und Probleme werden nach oben eskaliert. Kontrolle erfolgt über Monitoring und Reporting, wobei der Fokus auf der Kontrolle der Ziele und ihrer Erreichung liegt. Die Mitarbeitenden übernehmen Mitverantwortung, indem sie für die Erreichung ihrer Ziele und einen Teil der Umsetzung der strategischen Ziele der Organisation verantwortlich sind.

Dieses Modell des Managements wird von großen Konzernen und Organisationen im regulierten Umfeld genutzt, da es skalierbar ist.

• Management