Dieser Beitrag zeigt Zusammenarbeitsmodelle, wie Projekte in einem regulierten Umfeld agil abgewickelt werden. Dieser Blog basiert auf einem Vortrag an der ZHAW im CAS Agiles IT-Projektmanagement. Willkommen.
Reguliert bedeutet, dass ein Regulator Einschränkungen bezüglich des Prozesses und der Technologie eines Projektes vorschreibt und dessen Einhaltung auch überprüft respektive überprüfen lässt. Es ist also nicht nur das eigentliche Produkt, also das Erzeugnis reguliert, sondern auch der gesamte Entwicklungsprozess.
Was beispielsweise nicht reguliert ist, ist die Produktion von Software für Banken und Versicherungen. Der hiesige Regulator wacht nicht darüber, ob der Softwareentwicklungsprozess und somit das Projektmanagement eines Softwarevorhabens konform ist. Unternehmen begnügen sich mit eigenen internen Vorgaben und Richtlinien. Hingegen ist das Produkt, z.B. eine Versicherung und ein Anlagenkonstrukt, streng reguliert, muss freigegeben und gelistet werden.
Als Faustregel ist der Prozess dort reguliert, wo Strom fliesst. Alle elektrischen Systeme unterliegen der Functional Safety (IEC 61508). Selbst Smartphones sind reguliert. Allerdings nicht alle Komponenten. Das Betriebssystem beispielsweise abstrahiert vieles. Gewöhnliche App-Entwickler müssen sich nicht um das Batterie-Management kümmern und sind daher auch nicht reguliert.
Als weitere Faustregel gilt, wo Mensch und Leben gefährdet sind, hütet ein Regulator den Entwicklungsprozess. Für medizinische Geräte ist das selbsterklärend. Reguliert sind beispielsweise auch Rolltreppen und Lifte; in manchen Ländern sogar noch strikter, wo Hochhäuser ganze Städte säumen.
Nicht-regulierte Vorhaben sind in einem Projektstrukturplan organisiert. Dieser kann klassisch oder agil gegliedert sein. Ein Projektstrukturplan entspricht der Planungsdimension eines Projektes. Das ist unseres Erachtens die minimalste Struktur für ein Projekt. Für eine lokale Zähl-App ist ein Projektstrukturplan relativ überschaubar und hat höchstens zwei Abstraktionsstufen. Ein komplettes Liftsystem hingegen bedingt weitaus mehr Abstraktionsstufen, denn komplexe Systeme bestehen aus einem elektrischen System mit Software und einem mechanischen System, das entsprechend geplant und strukturiert werden muss. Gewisse Regulatorien verlangen einen angemessenen Projektstrukturplan, in Standards sind auch Vorlagen vorgeschlagen. In der Hauptsache gilt, dass man etwas hat (Evidenz).
Je nach Branche und/oder System fordert der Regulator eine Spezifikationsdimension. Diese ist meistens vom generischen V-Modell abgeleitet. Darin sind alle Artefakte gelistet und auch deren Beziehungen respektive deren Nachvollziehbarkeit. Diese Spezifikationsdimension ist nicht verhandelbar. Eine produktbasierte Risikoanalyse kann eine lokale Anpassung gut begründen.
Diese Spezifikationsdimension kann jedoch nicht komplett upfront entwickelt werden. Das wäre vermessen und entspräche nicht den agilen Prinzipien. Die Spezifikationsdimension entsteht mit den typischen Scrum Sprints und ist in der Definition of Done abgelegt und Teil der built-in-quality, siehe auch unser Blog Wie Prozessqualität Kosten reduziert. Gewisse Artefakte, z.B. die obersten System Requirements, sollten allerdings im Voraus skizziert werden; sie wegweisen die gesamte Systementwicklung. Sowieso müssen die Anforderungen des Regulators berücksichtigt werden, der unterschiedliche Artefakte gerne in Meilensteine kombiniert und diese abnimmt.
Unternehmen in manchen Branchen sind projektorientiert aufgestellt. Sie entwickeln individuelle Lösungen, die untereinander nichts gemein haben. Ein einzelnes Projekt kann Jahre dauern. Diese Unternehmen haben Projektleitende dahingehend ausgebildet, als dass sie Kundenanforderungen in technische Anforderungen übersetzen können und von Team zu Team wechseln. Eine solche Organisation ist nicht zu verachten, sondern optimiert lediglich ihre Bedürfnisse in Bezug auf die vorherrschenden Projektentwicklungs-Vorgaben (oder projektbasierte Produktentwicklungsorganisation).
Unternehmen aus anderen Branchen verfügen über stabile Teams, wo Projekte allenfalls ebendiese Teams finanzieren. Eine solche Organisation ist nicht nach Projekten gruppiert. Es sind stabile Teams, welche die Arbeit erledigen. Diese Organisation kennt man in der Szene auch als produktorientierte Organisation (oder teambasierte Produktentwicklungsorganisation).
Für beide Organisationsmuster stellen wir Modelle bereit. Modelle sind allerdings bloss Modelle. Sie müssen in Workshops lokalisiert und befüllt werden, insbesondere basierend auf den regulatorischen Anforderungen. Ebenso sind unsere Modelle auf Produktentwicklungsorganisationen wie beispielsweise Forschung und Entwicklung fokussiert. Die Modelle beantworten auch nicht, wie die Aufbauorganisation geregelt ist. Es sind reine Ablaufmodelle.
Wir stellen uns eine Art "Baukasten" für Projekte innerhalb der Organisation vor. Diese Projekte verfügen über eine intensive "Inception"-Phase. Dort wird erledigt, was für den Projektverlauf unerlässlich ist:
Das Vorgehen gleicht einer Iteration 0. Fokus ist, alle notwendigen Voraussetzungen zu schaffen, damit ein Team arbeitsfähig und mit den regulatorischen Anforderungen konform ist.
Danach operiert das Projektteam in einem ewigen Scrum-Zyklus. Alle notwendigen Aktivitäten, um ein Produktinkrement regulatorisch konform zu entwickeln, sollten innerhalb eines Sprints angestrebt werden.
In einer teambasierten Produktentwicklungsorganisation ist die Organisation nicht nach Projekten oder gar Produkten gruppiert, sondern nach Teams. Die Mitarbeitenden sind ihren Teams zugewiesen. Die Teams holen sich die Arbeit.
Solche auf Deutsch "stabilen Teams" sind ausgeglichen hinsichtlich ihren Fähigkeiten und vereinen alle Disziplinen, die notwendig sind, um ein Produktinkrement zu entwickeln. Sie funktionieren in einem klassischen Scrum Modus.
Um die regulatorische Komplexität zu bedienen, flankieren vier spezielle Teams die stabilen Teams.
Diese Strukturierung eignet sich für Produktentwicklungsorganisationen, wo mehrere Teams gleichzeitig an Produkten arbeiten (müssen).
Alle Organisationen, die am Markt entwickeln, müssen diesen Markt und dessen Regulator würdigen. Ein geschicktes Target Operating Model (TOM) für eine Produktentwicklungsorganisation ist unerlässlich.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.