Projektmanagement und Vorgehensmodelle 2025 PDF Free Download

Name: Projektmanagement und Vorgehensmodelle 2025 PDF
Author: ForestgreenFox

1 / 234

0 views•234 pages

Projektmanagement und Vorgehensmodelle 2025 PDF Free Download

Projektmanagement und Vorgehensmodelle 2025 PDF free Download. Think more deeply and widely.

Oliver Linssen, Alexander Volland, Enes Yigitbas,

Martin Engstler, Martin Bertram, Eckhart Hanser,

Axel Kalenborn (Hrsg.)

Projektmanagement und Vorgehensmodelle 2025

PVM 2025

Post-Agilität, Resilienz, Transformation

Gemeinsame Tagung der Fachgruppen

Projektmanagement (WI-PM) und

Vorgehensmodelle (WI-VM)

im Fachgebiet Wirtschaftsinformatik

der Gesellschaft für Informatik e.V.

in Kooperation mit der Fachgruppe

IT-Projektmanagement der GPM e.V. und

dem PMI Germany Chapter e.V.

20. und 21. November 2025

in Hameln

Gesellschaft für Informatik e.V. (GI)

Lecture Notes in Informatics (LNI) - Proceedings

Series of the Gesellschaft für Informatik (GI)

Volume P-371

ISSN 2944-7682 (Online)

Volume Editors

Prof. Dr. Oliver Linssen, FOM Hochschule für Oekonomie und Management,

Bergische Universität Wuppertal (oliver.linssen@fom.de)

Alexander Volland, Union Investment Services & IT GmbH

(alexander.volland@union-investment.de)

Dr. Enes Yigitbas, Universität Paderborn (enes@mail.uni-paderborn.de)

Prof. Dr. Martin Engstler, Hochschule der Medien Stuttgart (engstler@hdm-stuttgart.de)

Dr. Martin Bertram, PMI Germany Chapter e. V. (martin.bertram@pmi-gc.de)

Prof. Dr. Eckhart Hanser, DHBW Lörrach (hanser@dhbw-loerrach.de)

Prof. Dr. Axel Kalenborn, Universität Trier (kalenbor@uni-trier.de)

Series Editorial Board

Andreas Oberweis, KIT Karlsruhe,

(Chairman, andreas.oberweis@kit.edu)

Torsten Brinda, Universität Duisburg-Essen, Germany

Dieter Fellner, Technische Universität Darmstadt, Germany

Ulrich Frank, Universität Duisburg-Essen, Germany

Barbara Hammer, Universität Bielefeld, Germany

Falk Schreiber, Universität Konstanz, Germany

Wolfgang Karl, KIT Karlsruhe, Germany

Michael Koch, Universität der Bundeswehr München, Germany

Heiko Roßnagel, Fraunhofer IAO Stuttgart, Germany

Kurt Schneider, Universität Hannover, Germany

Andreas Thor, HFT Leipzig, Germany

Ingo Timm, Universität Trier, Germany

Karin Vosseberg, Hochschule Bremerhaven, Germany

Maria Wimmer, Universität Koblenz-Landau, Germany

Dissertations

Rüdiger Reischuk, Universität Lübeck, Germany

Thematics

Agnes Koschmider, Universität Kiel, Germany

Seminars

Judith Michael, RWTH Aachen, Germany

 Gesellschaft für Informatik, Bonn 2025

This book is licensed under a Creative Commons BY-SA 4.0 licence.

Geleitwort

Liebe Teilnehmer:innen, geschätzte Forscher:innen, sehr geehrte Damen und Herren,

es ist mir eine große Freude, Sie zur diesjährigen Fachtagung „Projektmanagement und

Vorgehensmodelle“ an der Hochschule Weserbergland in Hameln willkommen zu heißen.

Unter dem Motto „Post-Agilität, Resilienz und Transformation“ beschäftigen wir uns in

diesem Jahr mit der Frage, wie sich Projektmanagement in einer Welt weiterentwickelt,

in der klassische Ansätze und agile Methoden längst keine Gegensätze mehr sind, sondern

Teil einer neuen, hybriden Realität.

Die vergangenen Jahre haben gezeigt, dass Projekte unter Bedingungen zunehmendem

Veränderungsdruck, Unsicherheit und technologischem Wandel stattfinden. Resilienz

wird dabei zu einer Schlüsselkompetenz – sowohl auf organisatorischer Ebene als auch

im Projektteam. Zugleich eröffnen Digitalisierung, Künstliche Intelligenz und hybride Ar-

beitsformen neue Möglichkeiten, Projektarbeit effizient, nachhaltig und menschen-

zentriert zu gestalten.

Genau hier setzt die PVM 2025 an: In Fachvorträgen wie „Leadership für AI-Agents –

Wer führt die Künstliche Intelligenz?“ oder „Zwischen Agilität und Resilienz: Spannungs-

felder und das Potenzial post-agiler Ansätze in digitalen Plattformen“, in Kompaktbrie-

fings zu Themen wie „DevOps in 45 Minuten“ oder „Künstliche Intelligenz im Projekt-

management“ sowie in praxisnahen Berichten zu Transformationsprozessen werden aktu-

elle Herausforderungen und Lösungsansätze lebendig diskutiert. Damit bietet die Tagung

den idealen Rahmen, um theoretische Konzepte und praktische Erfahrungen miteinander

zu verknüpfen und gemeinsam Perspektiven für die Zukunft des Projektmanagements zu

entwickeln.

Die Hochschule Weserbergland als Gastgeber dieser Tagung verbindet praxisnahe akade-

mische Ausbildung mit einer engen Vernetzung in die regionale Wirtschaft und Verwal-

tung. Mit ihrer Ausrichtung auf zukunftsorientierte duale und berufsbegleitende Studien-

gänge, Weiterbildungsangeboten für Unternehmen und angewandte Forschung bietet sie

ein hervorragendes Umfeld für den interdisziplinären Dialog zwischen Wissenschaft und

Praxis.

Hameln, bekannt durch seine historische Altstadt und eingebettet in die reizvolle Land-

schaft des Weserberglands, schafft darüber hinaus einen inspirierenden Rahmen für Be-

gegnungen und Austausch.

Mein besonderer Dank gilt den fachlichen Ausrichtern – den Fachgruppen „WI-PM“ und

„WI-VM“ der Gesellschaft für Informatik, der Fachgruppe „IT-Projektmanagement“ der

Deutschen Gesellschaft für Projektmanagement (GPM) und dem PMI Germany Chapter

– sowie dem Programmkomitee, den engagierten Organisator:innen und allen Mitwirken-

den, die diese Tagung möglich gemacht haben.

Ich wünsche Ihnen inspirierende Diskussionen, wertvolle Impulse für Ihre Arbeit und

viele neue Kontakte. Möge die PVM 2025 dazu beitragen, gemeinsam Wege zu gestalten,

wie Projektmanagement im Zeichen von Post-Agilität, Resilienz und Transformation er-

folgreich weitergedacht werden kann.

Mit herzlichen Grüßen

Prof. Dr. Peter Britz

Präsident

Hochschule Weserbergland

Vorwort

Liebe Leserinnen und Leser,

ist Agilität noch aktuell, oder sind wir schon in der 'Post-Agilität' angekommen? Kann

sich ein gutes Team überhaupt noch leisten, strikt einem vorgegebenen Vorgehensmodell

– sei es agil oder traditionell – zu folgen? Vielmehr scheinen Resilienz und Transformation

die entscheidenden Faktoren für Projekterfolg zu sein. Vor diesem Hintergrund stellt sich

die Frage, ob die einst sehr einfachen und von Pragmatik geprägten Werte und Prinzipien

der agilen Softwareentwicklung immer noch Relevanz haben oder einer Neuinterpretation

oder Neudefinition bedürfen? Und wie kann KI das Team dabei unterstützen, Komplexität

zu bewältigen, Resilienz zu stärken und Transformation aktiv zu gestalten?

Diesen drängenden Fragen wollen sich unsere beiden GI-Fachgruppen Projektmanage-

ment (WI-PM) und Vorgehensmodelle (WI-VM) in unserer diesjährigen gemeinsamen

Tagung „Projektmanagement und Vorgehensmodelle“ in Hameln stellen. Mit dem Leit-

thema ‚Post-Agilität, Resilienz, Transformation‘ setzt sich die PVM 2025 mit diesen The-

men aus Sicht von Wissenschaft und Praxis auseinander und diskutiert in den Tagungs-

beiträgen mögliche Lösungsansätze.

Die Fachtagung eröffnet die beiden Konferenztage mit einem eingeladenen Key-Note-

Vortrag. Das Hauptprogramm umfasst 15 ausgewählte Beiträge aus Praxis und Wissen-

schaft, die einen wissenschaftlichen Review-Prozess durchlaufen haben (Annahmequote

47%) und in diesem Tagungsband veröffentlicht werden. Wir möchten uns an dieser Stelle

ausdrücklich bei den Mitgliedern des Programmkomitees bedanken, die durch ihre Begut-

achtung der eingereichten Beiträge einen objektiven Bewertungsprozess erst möglich ge-

macht haben.

Ergänzend dazu liefern drei ausgewählte Reports weitere Impulse aus der Praxis, die mit

dem Auditorium direkt diskutiert und vertieft werden können. Mit Workshops und Kom-

paktbriefings wird die Tagung um ein attraktives Schulungsprogramm ergänzt. Eine Ex-

kursion und das Konferenzdinner bieten reichlich Gelegenheit für den Austausch zwi-

schen den Teilnehmern und den Fachgruppen.

Unser besonderer Dank gilt der Gastgeberin der PVM 2025, der Hochschule Weserberg-

land in Hameln. Auch danken wir unseren Kooperationspartnern GPM Deutsche Gesell-

schaft für Projektmanagement e.V. (Fachgruppe IT-Projektmanagement) und dem PMI

Germany Chapter e.V. für die langjährige gute Zusammenarbeit. Wir bedanken uns an

dieser Stelle ebenso bei all denen, die an der Organisation und der Gestaltung dieser Ta-

gung beteiligt sind.

Wir hoffen, dass der vorliegende Tagungsband für Sie neue Erkenntnisse, authentische

Erfahrungen und Anregungen enthält. Wir würden uns freuen, die eine oder andere Fra-

gestellung auch in der GI-Fachgruppenarbeit zu vertiefen. Informationen zu Workshops,

Terminen und Kontakten finden Sie auf den Internetseiten der Fachgruppe Vorgehensmo-

delle WI-VM (https://fg-wi-vm.gi.de/) und der Fachgruppe Projektmanagement WI-PM

(https://fg-wi-pm.gi.de/).

Wir wünschen Ihnen allen eine anregende, erkenntnisreiche und unterhaltsame PVM 2025

in Hameln mit vielen spannenden Diskussionen rund um rund um neue Wege des Arbei-

tens in Projekten.

Lörrach, Frankfurt am Main im September 2025

Eckhart Hanser, Sprecher der GI-Fachgruppe Vorgehensmodelle

Alexander Volland, Sprecher der GI-Fachgruppe Projektmanagement

Programmkomitee

Vorsitz

Prof. Dr. Eckhart Hanser, Sprecher der

Fachgruppe Vorgehensmodelle

Dr. Enes Yigitbas, Stv. Sprecher der

Fachgruppe Vorgehensmodelle

Alexander Volland, Sprecher der Fach-

gruppe Projektmanagement

Prof. Dr. Axel Kalenborn, Stv. Sprecher

der Fachgruppe Projektmanagement

Mitglieder

Dr. Martin Bertram, PMI Germany

Chapter e. V.

Prof. Dr.-Ing. Hans Brandt-Pook, FH

Bielefeld

Prof. Dr. Martin Engstler, Hochschule

der Medien Stuttgart

David Faißt, IFS Consulting GmbH

Dr. Thomas Greb, Thomas Greb

Consulting

Dr. Marvin Grieger, Universität Pader-

born

Prof. Dr. Eckhart Hanser, DHBW

Lörrach

Prof. Dr. Timm Eichenberg, Hoch-

schule Wesbergerland

Prof. Dr. Andreas Helferich, Interna-

tional School of Management

Prof. Dr. Georg Herzwurm, Universität

Stuttgart

Silke Homann-Vorderbrück, Amt Ei-

derstedt

Prof. Dr. Oliver Linssen, Stv. Sprecher

der Fachgruppe Vorgehensmodelle,

Sprecher der Fachgruppe IT-Projektma-

nagement der GPM

Prof. Dr. Martin Engstler, Hochschule

der Medien Stuttgart

David Faißt, IFS Consulting GmbH

Luca Randecker, Hochschule der Me-

dien Stuttgart

Prof. Dr. Axel Kalenborn, Universität

Trier

Gerrit Kerber, Gerrit Kerber Unterneh-

mensberatung

Ralf Kneuper, IU Internationale Hoch-

schule

Prof. Dr. Marco Kuhrmann, Hoch-

schule Reutlingen

Prof. Dr. Oliver Linssen, Universität Wup-

pertal

Prof. Dr. Joachim Sauer,

NORDAKADEMIE

Luca Randecker, Hochschule der Me-

dien Stuttgart

Alexander Volland, Union Investment

Services & IT GmbH

Prof. Dr. Helge Frank Wild, Wilhelm

Büchner Hochschule

Dr. Enes Yigitbas, Universität Pader-

born

Organisationskomitee

Alexander Volland, Sprecher der Fach-

gruppe Projektmanagement

Prof. Dr. Axel Kalenborn, Stv. Sprecher

der Fachgruppe Projektmanagement

Prof. Dr. Eckhart Hanser, Sprecher der

Fachgruppe Vorgehensmodelle

Dr. Enes Yigitbas, Stv. Sprecher der

Fachgruppe Vorgehensmodelle

Prof. Dr. Oliver Linssen, Stv. Sprecher

der Fachgruppe Vorgehensmodelle,

Sprecher der Fachgruppe IT-Projektma-

nagement der GPM

Dr. Martin Bertram, Vorstand PMI Ger-

many Chapter e.V.

Prof. Dr. Martin Engster, Hochschule

der Medien Stuttgart

Martin Bertram, PMI Germany Chapter

Timm Eichenberg, Hochschule Weser-

bergland

David Faißt, IFS Consulting GmbH

Michael Städler, Hochschule Weser-

bergland

Gastgeber

Hochschule Weserbergland

Sponsoren

liquidmoon GmbH

Kooperationspartner

GPM Deutsche Gesellschaft für Projektmanage-

ment e.V., Fachgruppe IT-Projektmanagement

Project Management Institute (PMI)

Germany Chapter e. V.

Inhaltsverzeichnis

Teil I – Beiträge im Hauptprogramm

Larissa Koch de Souza, Luca Randecker und Martin Engstler

Wege zur Post-Agilität – Eine Analyse der letzten zehn Jahre PVM-Fachtagung ........ 17

Larissa Koch de Souza und Martin Engstler

Zwischen Agilität und Resilienz: Spannungsfelder und das Potenzial post-agiler

Ansätze in digitalen Plattformen ................................................................................... 45

Marco Kuhrmann, Philipp Straub, Julio Guzman und Jil Klünder

Towards a Hybrid Process for Integrating Systems, Software, and Games

Engineering ................................................................................................................... 59

Ninja Leikert-Boehm, Katja Kurz, Michèle Trebo und Philipp Matter

Fit for Agility? Exploring Person-Job Fit in SAFe Teams ............................................ 71

Elisabeth Schwarz und Timm Eichenberg

Einsatz agiler Projektmanagementmethoden in KMU: Eine qualitative Untersuchung

in der Maschinen- und Anlagenbau-Branche................................................................ 83

Kokulan Thanabalan und Axel Kalenborn

Von Anfang an mit KI: Lösungsskizzen mit intelligenten Komponenten gestalten ...... 101

Jan Wehinger

Wer führt die KI – und wie? Oder führt die KI uns? ................................................... 113

Teil II – Beiträge der Session „Future Track“

Sarah Brandt, Sven Theobald, Pascal Guckenbiehl und Alexander Krieg

Post Agility – A Review and Outlook .......................................................................... 131

Rebecca Fischer und Karoline Busse

Resilient Governance: Securing Public Services by Implementing Business Continuity

Management Systems in German Municipal Administrations .................................... 143

Claus Hüsselmann und Janek Hergenröder

Zwischen Stabilität und Anpassungsfähigkeit ‒ Entwicklung und Anwendung eines

Reifegradmodells für Lean-Adaptive Project Portfoliomanagement .......................... 161

Jil Klünder, Jakob Droste, Florian Heintz, Marion Wiese und Marco Kuhrmann

How to Mitigate Technical Debt in Startups: Extending the Entrepreneurial Software

Engineering Model ...................................................................................................... 181

Jessica Nagel

Digitale Kompetenz im Projektmanagement: Ein Kompetenzstrukturmodell für das

digital strukturierte Projektmanagement ................................................................... 193

Kendra Pöhlmann und Julia Hodapp

Transformational Skills für die digitale und nachhaltige Transformation: Innere

Entwicklung als Schlüssel zur Veränderung von (Projektmanagement-) Kultur ........ 199

Bernhard Schloß

Die Table of PM Elements als Wegweiser im post-agilen Projektalltag ..................... 209

Sven Theobald und Christopher Rottmann

Challenges of Integrating Agile Development and Analytical Quality Assurance ...... 215

Teil III – Praxisbeiträge

Sercan Cevik

Agil, um jeden Preis? .................................................................................................. 227

Thorsten Nottebaum

Agil gescheitert? Warum agile Transformationen ins Sto-cken geraten – und wie

Projekte trotzdem gelingen ......................................................................................... 229

Klaus Schopka

Programmmanagement zur Steuerung strategischer Transformationen .................... 231

Jens Zimmermann und Christian Zender

Zwischen Theorie und Praxis: Agilität im Alltag der Atruvia .................................... 233

Teil I

Beiträge im Hauptprogramm

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 17

Wege zur Post-Agilität: Eine Analyse der letzten zehn Jahre

PVM-Fachtagung

Larissa Koch de Souza1, Luca Randecker2 und Martin Engstler3

Abstract: Das Verständnis von Agilität hat sich in den letzten Jahren zunehmend von einem festen

Methodenset hin zu einem flexiblen, kontextsensitiven Leitfaden gewandelt. Dieses Paper

untersucht auf Basis einer systematischen Auswertung der Beiträge der Fachtagungsreihe

„Projektmanagement und Vorgehensmodelle“ (PVM) aus Jahren 2014-2024, inwiefern sich ein

post-agiles Verständnis etabliert hat. Die Ergebnisse zeigen einen Wandel agiler Praktiken entlang

methodischer, kultureller und regulatorischer Merkmale. Die Analyse macht deutlich, dass post-

agile Ansätze keine Ablehnung vom agilen Grundgedanken darstellen, sondern eine strategische

sowie eine operative Weiterentwicklung abbilden. Die Ergebnisse liefern somit einen theoretisch

fundierten Beitrag zur Diskussion um die Zukunft agiler Organisations- und Projektpraktiken.

Darauf basierend schließt der Beitrag mit Impulsen für die Gestaltung post-agiler Ansätze ab.

Keywords: Agilität; Organisationsformen; Post-Agilität; Projektmanagement; PVM-Fachtagung;

Vorgehensmodelle

1 Einleitung

Agilität hat sich seit der Veröffentlichung des Agilen Manifests [Be01] als fester

Bestandteil und anerkanntes Konzept moderner Projektmanagementpraktiken etabliert.

Auch in der Forschung wurde im Rahmen wissenschaftlichen Fachtagungen, wie

beispielsweise der Fachtagungsreihe „Projektmanagement und Vorgehensmodelle“

(PVM) der Gesellschaft für Informatik e.V., das Verständnis von Agilität wiederholt und

intensiv vor dem Hintergrund jeweils aktueller empirischer Studien und Erfahrungs-

berichte aus der Praxis reflektiert. Doch immer häufiger werden aktuelle Diskurse

aufgeworfen, inwiefern diese ursprünglich innovative Organisations- und Planungsform

zunehmend an seine Grenzen stößt und eine agile Ermüdung herrscht („agile fatigue“

[Co09]). In der Praxis lassen sich zunehmend Modelle beobachten, die sich vom

ursprünglichen Agilitätsverständnis entfernen und eine Neuinterpretation wagen. So

erkennt [Ti18] eine Verbreitung hybrider Modelle, die klassische und agile Elemente

bewusst miteinander kombinieren. [KL14] bestätigen diese Dominanz von klassischen

oder hybriden Modellen im Verhältnis zu agilen Ansätzen und [Or19] wiederum rückt

anstelle der Agilität den Ansatz der Antifragilität in den Fokus.

1 Hochschule der Medien Stuttgart, Fakultät Information & Kommunikation, Nobelstr. 10, 70569 Stuttgart,

kochdesouza@hdm-stuttgart.de

2 Hochschule der Medien Stuttgart, Fakultät Information & Kommunikation, Nobelstr. 10, 70569 Stuttgart,

randecker@hdm-stuttgart.de

3 Hochschule der Medien Stuttgart, Fakultät Information & Kommunikation, Nobelstr. 10, 70569 Stuttgart,

engstler@hdm-stuttgart.de

18 Larissa Koch de Souza et al.

Diese Entwicklungen werfen die grundlegende Frage auf, ob das Konzept der Agilität in

seiner ursprünglichen Form noch zeitgemäß ist oder ob eine Neuinterpretation und

Weiterentwicklung des emergent gewachsenen Agilitätsverständnisses und dessen

Umsetzung unter den veränderten Rahmenbedingungen notwendig ist [LKM15]. Einige

Publikationen greifen diese Perspektive bereits früh auf und fordern so beispielsweise eine

Weiterentwicklung des Ansatzes zu verstärkten hybriden Praktiken, erhöhter Team-

Autonomität und die breitere Berücksichtigung von zukunftsrelevanten Zielstellungen für

die agile Organisationsplanung [BPM11; LKM15]. Vor diesem Hintergrund bietet die

Idee der Post-Agilität einen analytischen Rahmen, der es erlaubt, die Entwicklung des

Agilitätsverständnisses zukunftsorientiert weiterzudenken. Die Vorsilbe „post“ verweist

in diesem Zusammenhang infolgedessen auch nicht auf eine vollständige Abkehr oder gar

ein Scheitern von Agilität, sondern auf die tiefliegende Transformation des Ansatzes

[Ho20].

2 Methodisches Vorgehen

Das vorliegende Paper nimmt sich den Fragen an, wie sich das Verständnis der Agilität

über die letzten Jahre entwickelt hat, ob sich daraus ein erkennbarer Stand der Post-

Agilität identifizieren lässt und wenn ja, wie dieser zu auch für die Zukunft der Agilität zu

deuten ist. Die zentrale Forschungsfrage lautet: Wie hat sich Agilität entlang der letzten

Jahre in Richtung einer Post-Agilität weiterentwickelt und was sind zukunftsleitende

Entwicklungsrichtungen? Methodisch basiert die Untersuchung auf einer theoriegeleiteten

Literaturrecherche sowie der strukturierten Auswertung durch eine thematische

Taxonomie von relevanten Beiträge aus der deutschsprachigen Projektmanagement- und

Vorgehensmodellforschung. Als zentrale Datenbasis dient die wissenschaftliche

Fachtagungsreihe „Projektmanagement und Vorgehensmodelle“ (PVM) der Gesellschaft

für Informatik (GI), deren Beiträge aus den letzten 10 Jahren (von 2014 bis 2024)

analysiert werden. Ausgenommen werden dabei die Jahre 2020 bis 2021, innerhalb

welcher entlang der Covid-19-Pandemie keine PVM-Fachtagung im klassischen Sinne

inklusive vollständigem Tagungsband stattfand. Die PVM-Reihe fungiert dabei nicht nur

als Sammlung empirischer Erkenntnisse, sondern auch als Diskursraum, in dem sich

methodologische Trends, kulturelle Spannungsfelder und Innovationsdilemma im

Projektmanagement der letzten zehn Jahre im Bereich des Projektmanagements und der

Vorgehensmodelle nachzeichnen lassen.

Die Auswahl der Beiträge entlang der berücksichtigten Jahre erfolgt anhand der

inhaltlichen Relevanz der Beitragstitel zu den Themen Agilität, Vorgehensmodelle und

post-agile Impulse. Die Suchbegriffe, nach welchen gefiltert wurde für einen Einschluss,

lauteten: „Agil*“, „Hybrid*“, „Vorgehensmodell“, sowie die beispielhaften Frameworks

von Agilität „Lean Management“ und „Scrum“. Beiträge mit mindestens einem der

thematischen Schlüsselbegriffe im Titel werden vollständig im Volltext analysiert und auf

ihre theoretische Fundierung, Praxisnähe und thematischen Ergebnisse geprüft. Es wurden

sowohl Volltext-Beiträge, als auch Future-Track-Impulsbeiträge berücksichtigt. Key-

Wege zur Post-Agilität 19

Notes und Präsentationen wurden ausgeschlossen. Insgesamt wurden somit 58 Beiträge in

die Analyse eingeschlossen.

Für den Datensatz der eingeschlossenen PVM-Beiträge der Thematik wurde eine

thematische Taxonomie zur Strukturierung der Ergebnisse ergänzt und anhand dessen

ausgewertet. Die Taxonomie ist Teil der textbasierten Analyse der Thematik und

klassifiziert die Publikationen und thematische Verschiebungen und Veränderungen

entlang der letzten zehn Jahre. Die folgenden thematischen Kategorien sind dabei gewählt

worden:

• Das Agilitätsverständnis beschreibt, wie im Rahmen des betrachteten Beitrags

Agilität definiert und beleuchtet wird. Kernkonzepte welche erwähnt werden,

Chancen sowie erkannte Grenzen des Agilitätkonzepts werden hierbei

mitaufgenommen und bilden ab, in welchen Zusammenhängen Agilität entlang

der verschiedenen Jahre betrachtet wurde.

• Post-Agile Impulse umfassen konkrete Kritikpunkte des aktuellen

Agilitätsverständnisses und bringen Empfehlungen zur Weiterentwicklung der

Agilität in Richtung Post-Agilität auf. Dies beleuchtet somit im Rahmen der

Analyse den thematischen Fokusbereich im Kontext der Post-Agilität und wohin

sich das Begriffsverständnis entwickelt.

• Die Agilitätsansicht stuft ein, ob die Autoren agil-positive, neutrale oder agil-

kritische Aussagen zum ursprünglichen Agilitätsverständnis und den jeweils

gelebten agilen Praktiken äußern. Als agil-positiv wird gewertet, wenn das

ursprüngliche Verständnis von Agilität weiterhin als relevant und nützlich

eingestuft wird. Aussagen werden als agil-kritisch berücksichtigt, sofern sie

erkannte Grenzen, emergent auftretende Herausforderungen und den Bedarf zur

Weiterentwicklung des aktuellen Agilitätsverständnisses beleuchten. Beiträge

können mehrere Aussagen der verschiedenen Bereiche tätigen, in diesem Fall

wird die Veröffentlichung sowohl positiv als auch kritisch eingestuft. Eine

neutrale Einstufung erfolgt dann, wenn die Aussagen zu Agilität weder eindeutig

positiv oder negativ sind oder Aussagen unzureichend präzisiert sind.

Für jede dieser Kategorien fand auf Basis der gesammelten Informationen aus den

Volltexten der Beiträge eine Einstufung statt. Die vollständige Einstufung und Bewertung

der ausgewählten Beiträge entlang der Kategorien ist der Tabelle im Anhang zu

entnehmen. Ergänzend wurden ebenfalls die Formalia (Autoren, Jahr, Thema des

Konferenzjahres sowie Titel des Beitrages) in der Tabelle eingefügt.

20 Larissa Koch de Souza et al.

3 Ergebnisse

3.1 Trendverlauf der (Post-)Agilität entlang der PVM-Beiträge

Entlang der Verteilung der berücksichtigten Beiträge zeichnet sich bereits schon vor der

inhaltlichen Analyse der Beiträge eine deutlich sinkende Tendenz der Relevanz von

Agilität als thematischer Fokus in den PVM-Tagungsbeiträgen ab (s. Abb. 1). Während es

zu Beginn der PVM-Fachtagungsreihe und insbesondere bis 2019 ein Hoch der Thematik

gab, verbleibt die Anzahl der passenden Beiträge seit der Covid-19 Pause auf einem

Niedrigstand – wohlgleich sich die Anzahl der Beiträge eines Tagungsbandes auf einem

ähnlichen Niveau hält. Inwiefern dies bereits Andeutungen zur Verschiebung der Agilität

in Richtung Post-Agilität und einem nötigen Bedarf zum Überdenken des Projekt- und

Vorgehensmodells darlegt, wird in den weiteren thematischen Ergebnissen tiefergehend

analysiert. Es ist jedoch bereits festzuhalten, dass der Verlauf der Beiträge, welche Agilität

als eines ihrer Kernthemen im Titel betrachten, und der Beiträge, welche post-agile

Impulse im Sinne von Weiterentwicklungen des Agilitätskonzepts beinhalten, sehr

deckungsgleich ist. Es lässt sich folglich daraus schließen, dass nahezu alle Autoren,

welche Agilität in das Zentrum ihres Beitrages stellten, ebenfalls Ansätze zu möglichen

Weiterentwicklungen, Ergänzungen oder Änderungen der agilen Projekt- und

Vorgehensmodelle einbringen.

Abbildung 1: Post-Agilität und Agilitätstrendverlauf

Wege zur Post-Agilität 21

3.2 Agilitätsverständnis

Anschließend an die Verteilung der agil-thematischen Beiträge, wurde in einem nächsten

Schritt der Inhalt der verschiedenen Agilitätsverständnisse analysiert. Dabei konnte

festgestellt werden, dass die im Zeitverlauf genannten verschiedenen Kernmerkmale, die

das Bild agile Projekt- und Vorgehensmodelle geprägt haben, nicht durchgängig

konsistent und genannt wurden. Für eine Auswertung der relevantesten Merkmale eines

agilen Vorgehensmodells wurden ausschließlich Aspekte berücksichtigt, welche

mindestens in fünf verschiedenen Beiträgen genannt worden sind. Die Analyse zeigt, dass

sich über die unterschiedlichen Tagungsbände hinweg vier besonders häufig

wiederkehrende Positionen finden lassen: Erstens wird Agilität in den meisten Beiträgen

primär über konkrete Methoden und Frameworks wie z.B. Scrum, Kanban oder Lean

beschrieben (23 Nennungen: [Da14], [FSH14], [AE15], [Kn15], [Kr15], [Mü15], [Pe15],

[SRE15], [NMK16], [ÖD16], [WVM16], [Al17], [BJ17], [Di17], [Kl17], [Bä18], [KS18],

[SKN18], [HL19], [SB19], [VS23], [BMF24], [HS24]). Zweitens wird Agilität stark mit

einem kulturellen oder werteorientierten Mindset verknüpft (16 Nennungen: [FSH14],

[HK14], [DKZ15], [Kn15], [Kr15], [Kr16], [WH16], [WVM16], [BJ17], [Gr17], [Kü17],

[Bä18], [Ti18], [Bl19], [GT19], [Gu23]). Drittens wird Agilität regelmäßig im Kontext

von Führung, Management oder Governance betrachtet, das heißt in Bezug auf Steuerung

und organisatorische Einbettung (neun Nennungen: [Da14], [Mü15], [BJ17], [Bä18],

[CA18], [Fi18], [KTK18], [Kr19], [Gu23]). Zuletzt als viertes wird Agilität mit dem

Merkmal der Flexibilität und Anpassungsfähigkeit auf emergent auftretende

Anforderungen oder auch Herausforderungen gekennzeichnet (sieben Nennungen:

[AE15], [Kr15], [ÖD16], [Kr17], [CA18], [HS18], [Bl19]).

Abbildung 2: Trendverläufe der meistgenannten Merkmale zum Agilitätsverständnis

22 Larissa Koch de Souza et al.

Entlang dem Verständnis von Agilität auf Basis von methodischen Merkmalen und

Frameworks (#1) zeigt sich, dass Agilität weniger eine fest-formulierte

Methodensammlung beschreibt, sondern vielmehr als dynamischer Denk- und

Handlungsrahmen verstanden wird [Kn15]. Hierdurch offenbarten sich entlang der letzten

Jahre in der Umsetzung jedoch auch starke Defizite. [SH15] zeigen so zum Beispiel auf,

dass viele Entscheidungen über Funktionalitäten oft auf heuristischen und intuitiven

Einschätzungen basieren, welche nicht streng einem analytischen Ansatz folgten. Ähnlich

zeigen [WVM16] auf, dass Agilität oftmals nur mit einzelnen Praktiken oder Tools

verbunden wird (z. B. Stand-Up-Meetings oder Scrum-Boards), ohne eine reflektierte oder

tiefer verankerte Umsetzung agiler Prinzipien bzw. Werte zu berücksichtigen. Dieses

Problem liegt laut [HK14] sowie [KL14] auch in der vermeintlichen Flexibilität (#4) agiler

Ansätze, die zwar Anpassungen ermöglicht, in der Praxis jedoch häufig mit fehlender

Standardisierung und mangelnder Steuerung einhergeht. Insbesondere für große

Organisationen ist dieser Aspekt der methodisch-korrekten und vollständigen Umsetzung

von Agilität kaum umsetzbar [HK14]. Bezüglich dem Aspekt der Kultur (#2) wird Agilität

zudem primär als methodisches Hilfsmittel verstanden, ohne die dahinterliegende

Philosophie zu verinnerlichen und eine strukturelle Herangehensweise zu schaffen [Ti18].

Auffällig ist, dass dieses Problem der mangelnden kulturellen Verankerung insbesondere

2018 thematisiert wird, wohingegen das methodenbasierte Verständnis vor allem in den

früheren Jahren der PVM-Tagungsreihe ausschlaggebend war und die Nennungen dazu

seither stark abnahmen. Dies deutet auf eine gewisse Methodenmüdigkeit hin: Agilität

über die bereits ausgeschöpften Methoden zu definieren genügt somit nicht mehr. Ein

tragfähiges Agilitätsverständnis muss tiefer greifen und kulturell sowie organisatorisch

neu interpretiert werden. Insgesamt ist zudem festzustellen, dass die prägenden Merkmale

des Agilitätsverständnisses in den Beiträgen zu Beginn der PVM-Tagungsreihe deutlicher

präsenter waren als in den letzten PVM-Fachtagungen 2022-24. Das Verständnis von

Agilität streut sich zunehmend, sodass eine größere Vielfalt individueller Auffassungen

(<5 Nennungen) erkennbar wird.

Die Relation der Merkmale zueinander verdeutlicht Abb. 3: Während Methoden (#1) nach

wie vor das größte und zentrale Verständnismerkmal darstellen, werden Flexibilität (#4)

und Management (#3) als weniger häufig genannte, aber stark verbundene Aspekte

verstanden – häufig abgeleitet oder unmittelbar verknüpft mit dem Methodeneinsatz.

Kulturelle Aspekte (#2) stehen demgegenüber in einer gewissen Eigenständigkeit, da sie

im Diskurs oft losgelöst von den methodisch-regulierten Abläufen betrachtet werden. Auf

Basis der letztjährigen Entwicklungen ist dies jedoch ein Bereich, welcher immer näher in

die Methoden einzugliedern ist und welcher sich folglich den anderen Bereichen nähern

muss. Das gesamte Abbild aller meistgenannten Merkmale unterstreicht, dass sich das

Agilitätsverständnis nicht auf eine rein technische oder organisatorische Ebene reduzieren

lässt, sondern stets zwischen methodischer Praxis, kulturellem Mindset und

organisationaler Rahmung ausbalanciert werden muss.

Wege zur Post-Agilität 23

3.3 Post-agile Impulse

Die Auswertung der Beiträge zeigt, dass sich im (post-)agilen Diskurs über die Jahre

hinweg mehrere wiederkehrende Änderungs- bzw. Erneuerungsimpulse herausgebildet

haben (s. Abb. 4). Besonders deutlich sticht dabei die Forderung nach einer stärkeren

Kontext- und Situationsanpassung (A) hervor (Tailoring, hybride Ansätze, Baukasten-

logiken). Dieses Cluster A) bildet über den gesamten Untersuchungszeitraum hinweg den

sichtbarsten Schwerpunkt mit insgesamt 20 Nennungen entlang der PVM-Beiträge und

erreicht insbesondere 2018 mit sieben Nennungen einen markanten Höchstwert ([FSH14],

[KL14], [KZ14], [DKZ15], [Kn15], [Pe15], [ÖD16], [Gr17], [Kr17], [Kü17], [CA18],

[Fi18], [Ga18], [Ne18], [KS18], [Pr18], [SKN18], [Bl19], [DS19], [SS22]). Als zweiter

zentraler Impuls tritt die Betonung von Menschen, Kompetenzen und Kultur (B) hervor.

Hier stehen die Integration von HR, Coaching-Rollen oder auch die Schaffung

psychologischer Sicherheit im Vordergrund, die sich in insgesamt 13 Veröffentlichungen

wiederfinden ([AE15], [DKZ15], [Kr15], [Mü15], [SRE15], [KS18], [KTK18], [SKN18],

[Ti18], [Kr19], [Gu23], [HS24]). Auffällig ist in Cluster (B) dabei eine frühe Spitze im

Jahr 2015 sowie ähnlich zu Cluster A ein weiteres starkes Aufgreifen in 2018, was auf

Phasen hinweist, in denen die kulturellen und personalorientierten Dimensionen besonders

betont wurden und wo deutliches Verbesserungspotential entlang des agilen Projekt- und

Vorgehensmodells gesehen wurde. Ein dritter durchgängig relevanter Themenkomplex

betrifft die Skalierung und Governance (C) agiler Ansätze, also die Übertragung agiler

Prinzipien auf gesamte Organisationen, Programme oder Portfolios sowie die Einbettung

entsprechender Steuerungsmechanismen ([Mü15], [Pe15], [CA18], [GT1], [Kr19],

[Gu23], [VS23]). Das Cluster (C) wurde entlang der Jahre regelmäßig als Thema

betrachtet, zeigt jedoch keine extremen Höchstwerte wie der erkannte Bedarf nach

Situationsanpassung zeigt. Es liegt der Schluss nahe, dass Skalierung und Governance ein

konstantes Thema sind, welches bei agilen Projekt- und Vorgehensmodellen diskutiert

wird, jedoch bislang keiner akuten Priorisierung bedarf. An vierter Stelle steht die

Abbildung 3: Merkmale vom Agilitätsverständnis im Verhältnis zueinander

24 Larissa Koch de Souza et al.

Integration agiler Praktiken mit etabliertem, klassischem Projektmanagement (Hybrides

Projektmanagement, D), die vor allem 2014 und 2015 eine Rolle spielte ([HK14], [Pe15],

[SH15], [Sc15], [SRE15], [CA18]). Gleichwertig folgen als fünfter und sechster Impuls

einerseits die Verbindung mit DevOps und technischen Automatisierungsansätzen (E)

([Kn15], [SH15], [SRE15], [HS18], [Gö23]), andererseits die stärkere Ausrichtung auf

Wertorientierung und Metriken (F) ([SH15], [Kr16], [We17], [HL19], [SB19]). Beide

Themen erscheinen ab 2015, bleiben in den Folgejahren aber insgesamt diskontinuierlich

präsent.

Neben diesen wiederkehrenden Schwerpunkten wurden in der Analyse auch weitere,

punktuell auftretende Impulse identifiziert,beispielsweise die Anbindung an Design

Thinking oder die Führung in verteilter Teamstrukturen. Diese wurden jedoch in der

weiteren Analyse nicht weiter vertieft, da sie die gesetzten Schwelle von mindestens fünf

Nennungen nicht erreichten. Alles in allem wird deutlich, dass sich der post-agile Diskurs

nicht auf einen einzelnen Änderungsbedarf am Agilen Manifest [Be01] fokussiert, sondern

in Wellenbewegungen verschiedene Akzente setzt. Während die Kontext- und

Situationsanpassung (A) als stärkster Impuls erscheint, zeigt auch dieses Cluster innerhalb

der letzten Jahre seit der Covid-19 Pandemie ein deutliches Tief und weniger Bedeutung.

Auffällige Spitzen wiederum – etwa in 2015 und 2018 – deuten darauf hin, dass Diskurse

zu Post-Agilität oftmals in Reaktion auf konkrete methodische Debatten oder

Publikationsereignisse an Fahrt aufgenommen haben und sich dann entlang aller der

meistgenannten Impulse wiedergefunden haben.

Das in Abb. 5 dargestellte Verhältnis der post-agilen Impulscluster zueinander

verdeutlicht über den zeitlichen Verlauf hinweg nochmals die Gewichtung und

Abbildung 4: Trendverläufe der meistgenannten post-agilen Impulscluster

Wege zur Post-Agilität 25

wechselseitige Verknüpfung der Impulse. Am stärksten dominiert das Cluster der Kontext-

und Situationsanpassung (A), das nicht nur in seiner Häufigkeit, sondern auch in seiner

Funktion als Bezugspunkt für andere Impulse sichtbar wird. So erscheint etwa die

Integration hybrider Projektmanagementansätze (D) überwiegend als Ausprägung oder

Unterform dieser Anpassungslogik. Auch Skalierung & Governance (C) wie auch

Wertorientierung & Metriken (F) zeigen Überschneidungen, insofern sie jeweils Fragen

der organisationalen Einbettung und Steuerung aufwerfen. Im Vergleich dazu nehmen

Menschen, Kompetenzen und Kultur (B) eine eigenständige und zugleich zweitstärkste

Position ein, was die hohe, jedoch in den Beiträgen oftmals eigenständig aufgegriffene

Bedeutung sozialer und menschenorientierter Aspekte unterstreicht. Kleinere Cluster wie

DevOps & Automatisierung (E) ergänzen diesen Gesamtzusammenhang, ohne ihn in

seiner Struktur grundlegend zu verschieben und können so jedoch insbesondere bei

Skalierung & Governance (C) unterstützen und damit verbunden werden.

Abschließend ist festzuhalten, dass die Entwicklungen der Agilität der letzten Jahre hin zu

einer Post-Agilität ein mehrdimensionales Spektrum an Anpassungsbedarfen vorweisen,

welche teils bereits in der post-agilen Variante (methodische, inkrementelle Nutzung von

agilen Prinzipien) umgesetzt werden, und teils als ein Anforderungsbedarf an die

zukünftige Ausgestaltung einer neuinterpretierten Agilität gerichtet sind (z.B. verstärkte

kulturell-philosophische Umsetzung agiler Prinzipien). Es kann daher insgesamt ein

strategischer Paradigmenwechsel beobachtet werden. Unter Zuhilfenahme von

Kontextsensitivität, permanenter Reflexion organisationaler Routinen und einer

Verstetigung hybrider Ansätze [Ti18; SS22], können im Rahmen der Post-Agilität die

Elemente Flexibilität und Steuerbarkeit vereint werden und ein holistisches, strategisch-

versiertes Bild der agilen Projektmanagementmethoden kreieren.

Abbildung 5: Post-Agile Impulscluster im Verhältnis zueinander

26 Larissa Koch de Souza et al.

3.4 Wahrnehmung von agilen Projekt- und Vorgehensmodellen

Ergänzend zur inhaltlichen Analyse der Impulse wurde die Wahrnehmung von Agilität in

den betrachteten Beiträgen untersucht. Hierfür wurde erhoben, ob in den Texten positive,

kritische oder ausschließlich neutrale Argumentationen in Bezug auf Agilität nach

heutigem Verständnis aufgebracht wurden (s. Tabelle im Anhang). Wenn Beiträge sowohl

positive als auch kritische Argumente enthielten, wurden sie entsprechend beiden

Kategorien zugeordnet. Bei fehlender erkennbarer Positionierung erfolgte eine Einstufung

als neutral. Insgesamt zeigt sich, dass von den 58 berücksichtigten Beiträgen 43 positive,

31 kritische und 7 neutrale Argumentationen enthalten sind (s. Abb. 6). Es konnte entlang

der agilitätsfokussierten Beiträge der PVM-Tagungsbände 2014-2024 daher insgesamt

eine stärkere positive Perspektive und Argumentation zu agilen Projekt- und

Vorgehensmodellen erkannt werden. Die kritischen Einschätzungen kombinierten meist

wertschätzende Aussagen mit konstruktiven Entwicklungsimpulsen.

Spannend ist zudem der zeitliche Verlauf der Wahrnehmung, welcher noch einmal den

deutlichen Anstieg von agil-kritischen Stimmen insbesondere im Jahr 2018 offenlegt (s.

Abb. 7). Dennoch ist zu vermerken, dass entlang der letzten drei Jahre positive als auch

kritische Stimmen auf einen ähnlichen Nenner kommen. Nur wenige Beiträge nehmen

eine strikt neutrale Position ein. Es lässt sich festhalten, dass Agilität im untersuchten

Zeitraum zwar primär positiv konnotiert bleibt, jedoch zunehmend auch konstruktiv-

kritisch diskutiert wurde. Gerade diese Gleichzeitigkeit von positiver als auch kritischer

Wahrnehmung zeugt von Anerkennung und nicht von einem vollständigen Verwerfen von

Abbildung 6: Gesamtverteilung der Agilitätswahrnehmung

Wege zur Post-Agilität 27

agilen Ansätzen. So bestätigt sich der Bedarf nach post-agilen Weiterentwicklungen

entsprechend der in Kapitel 3.3. herausgearbeiteten Impulse.

4 Diskussion

Die analysierten Beiträge der PVM-Tagungsreihe 2014-2024 zeigen ein vielschichtiges

und dynamisches Bild zum Projektmanagement- und Vorgehensmodelldiskurs. Die

wissenschaftlich-empirischen Erkenntnisse zu Agilität und dem Agilitätsverständis, die

Reflexion der gelebten Praxis agiler Projekt- und Vorgehensmodelle sowie die erkannte

Notwendigkeit der Weiterentwicklung des Agilitätsverständnisses und die bereits

genannten post-agilen Impulsen sind eine gute Basis auf dem Weg in die Post-Agilität.

Zusammenfassend kristallisierten sich in der Diskussion drei zentrale Änderungsimpulse

für die Post-Agilität heraus: die Notwendigkeit kontext- und situationsspezifischer

Anpassung, die stärkere Berücksichtigung von Mensch und Kultur sowie die Ausweitung

auf Skalierung und Governance. Schließlich konnte gezeigt werden, dass Agilität zwar

weiterhin überwiegend positiv konnotiert bleibt, die kritische Reflexion jedoch deutlich

zugenommen hat und heute eine zentrale Grundlage für post-agile Weiterentwicklungen

darstellt. Die Ergebnisse sind methodisch jedoch durch verschiedene Faktoren

eingeschränkt. Erstens beruht die Analyse auf einer eigens definierten Taxonomie, die

zwar auf Basis der Literatur und Beitragsinhalte entwickelt wurde, jedoch immer auch

eine interpretative Auswahl darstellt. Zweitens umfasst der Datensatz ausschließlich die

PVM-Tagungsreihe 2014-2024. Diese Fokussierung ist insofern plausibel, als die PVM

stark auf Entwicklungen im Bereich Projektmanagement und Vorgehensmodelle

ausgerichtet ist und damit einen relevanten und aktuellen wissenschaftlichen Diskursraum

bildet. Zugleich unterliegt sie jedoch eigenen Einflussfaktoren: So prägten die

thematischen Aufrufe für Beitragseinreichungen einzelner Jahrgänge (z. B. 2015/2016 zu

Abbildung 7: Agilitätswahrnehmung (positive und kritische

Argumentationen) der PVM-Beiträge 2014-2024

28 Larissa Koch de Souza et al.

hybriden Projektansätzen) den Diskurs stark, was zur Häufung bestimmter

Argumentationen in bestimmten Jahren führte. Hinzu kommt der GI-Kontext der PVM-

Tagungsreihe, wodurch informatiknahe Perspektiven tendenziell stärker einfließen.

Darüber hinaus wurden im Rahmen der Analyse weitere, insbesondere für die Zukunft

relevante, Aspekte einer post-agilen Entwicklung festgestellt, welche entlang der Analyse

der letzten zehn Jahre so jedoch noch nicht in ausschlaggebender Relevanz auftraten. Zwar

wurden in einzelnen Beiträgen Impulse zu neuen Arbeitsformen (Remote-/verteilte

Teams), zum Einsatz von Technologien wie Künstlicher Intelligenz oder zu

Nachhaltigkeit und regulatorischen Verschiebungen aufgegriffen, sie konnten im

Betrachtungszeitraum 2014-2024 noch nicht als Treiber neuer Entwicklungslinien in den

Beiträgen identifiziert werden. Gerade diese Themen scheinen aber für zukünftige post-

agile Diskussionen zentral: Technologienutzung ist dabei nicht nur Arbeitsmittel, sondern

potenzieller Befähiger neuer Ausprägungen von Agilität und ermöglicht so beispielsweise

im aktuellen Umschwung zu verteilten Teams neue Möglichkeiten Agilität trotz

physischer Distanz umzusetzen und zu leben [RE24]. Hinzu kommt der Umgang mit KI

in der Projektarbeit, die sich von einer Rolle als Arbeitsmittel hin zu einem virtuellen

Arbeitspartner entwickelt hat und damit neue Kooperationsmuster in der Zusammenarbeit

von Mensch und Technik etabliert. Nachhaltigkeit und Regulierung wiederum können als

externe Rahmenbedingungen wirken, die Agilität neu herausfordern und gestalten [Ko23].

Vermehrt rücken solche Themen in den Vordergrund und teilen sich die Gemeinsamkeit,

dass hochgradig formalisierte und nachvollziehbare Prozesse gefordert werden [Gr23;

REH23], jedoch aufgrund fehlender Prüfbarkeit nicht ausreichend erfüllt werden können.

Diese Dimension der regulatorischen Dynamiken und Anforderung wird somit ebenfalls

im Sinne einer post-agilen Betrachtung vermehrt im Vordergrund stehen. Denn oftmals

stehen diese, auf Nachvollziehbarkeit und Stabilität zielenden Anforderungen, in einem

Widerspruch zu den iterativen und flexiblen Herangehensweisen der Agilität [Gr23].

5 Fazit

Insgesamt wird deutlich, dass sich das Verständnis von Agilität in den zehn Jahren PVM-

Tagung (2014-2024) zunehmend von starren Methoden hin zu einem flexiblen Denk- und

Handlungsrahmen verschoben hat, der neue Rahmenbedingungen miteinander vereinen

muss. Dabei veranschaulichen die Ergebnisse, dass die positive Wahrnehmung des agilen

Projekt- und Vorgehensmodells weiterhin und kontinuierlich leicht überwiegt, die

kritische Perspektive jedoch in nahezu gleichem Maße in den betrachteten Beiträgen

präsent ist, diese aber stets konstrukutiv mit Entwicklungsimpulsen verbunden wird. Die

zu Beginn bereits vermutete agile-fatigue spiegelte sich in den Ergebnissen wieder und

kritisierte insbesondere das Agilitätsverständnis mittels starrer Methoden und

Frameworks. Die Ergebnisse dieser inhaltlichen Analyse der PVM-Tagungsbeiträge

verdeutlicht so unter Nennung spezifischer post-agiler Impulse, dass methodische,

kulturelle sowie neue, regulatorische Herausforderungen eine Weiterentwicklung hin zu

post-agilen Ansätzen erforderlich machen und in Teilen bereits innerhalb der letzten Jahre

eingeleitet wurden. Post-Agilität wird somit auch im Rahmen der PVM nicht als eine

Wege zur Post-Agilität 29

Ablehnung der ursprünglichen agilen Prinzipien interpretiert, sondern versteht sich als

kontextsensitive Transformation von Agilität unter Berücksichtigung der neu erkannten

Anforderungen. Zukünftig bieten vor allem hybride und reflektierte Modelle ein hohes

Potenzial Agilität strategisch, ganzheitlich und nachhaltig weiterzudenken. Es sollten

jedoch im Rahmen einer Neuinterpretation des Ansatzes weitere Ergänzungen und

Hilfestellungen zur vollständigen Umsetzung von Agilität und dessen kultureller

Philosophie sowie Vereinbarkeit mit neuen Technologieentwicklungen sowie Governance

Anforderungen anvisiert werden. Offen bleibt nach dieser literaturbasierten Analyse, wie

ein belastbares, standardisiertes Rahmenwerk post-agiler Praktiken konkret ausgestaltet

werden kann. Die auf Basis der Analyse der PVM-Beiträge herausgearbeiteten Bedarfe

und Impulse liefern hierzu einen wertvollen Beitrag, sich auf die Post-Agilität

vorzubereiten und diese zu gestalten.

Literaturverzeichnis

[AE15] Aldushyna, A.; Engstler, M.: Erfolgsfaktoren bei der Umsetzung hybrider Projekte -

Ergebnisse einer Befragung und praktische Empfehlungen zur Umsetzung. In Engstler,

M.; Fazal-Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement

und Vorgehensmodelle 2015: Hybride Projektstrukturen erfolgreich umsetzen. LNI-

Band P-250, Gesellschaft für Informatik, S. 39–54, 2015.

[Al16] Albers, C.: Der Auswahlprozess von Vorgehensmodellen im Projektmanagement:

subjektive vs. objektive Kriterien. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Linssen, O.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2016: Arbeiten in hybriden Projekten: Das Sowohl-als-auch von

Stabilität und Dynamik. LNI-Band P-263, Gesellschaft für Informatik, S. 175–174,

2016.

[Al17] Albers, C.: Der Auswahlprozess von Vorgehensmodellen: Eine Übersicht und

Diskussion von Vergleichsansätzen. In Volland, A.; Engstler, M.; Fazal-Baqaie, M.;

Hanser, E.; Linssen, O.; Mikusz, M. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2017: Die Spannung zwischen dem Prozess und den Menschen im

Projekt. LNI-Band P-276, Gesellschaft für Informatik, S. 207–212, 2017.

[Bä18] Bächler, M.: Die Rolle der internen Kommunikation und deren Einflussmöglichkeiten

bei einer agilen Transformation von Organisationen. In Mikusz, M.; Volland, A.;

Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O. (Hrsg.): Projektmanagement

und Vorgehensmodelle 2018: Der Einfluss der Digitalisierung auf

Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band P-286,

Gesellschaft für Informatik, S. 207–216, 2018.

[BJ17] Baur, Michael; Jakob, Steffen (2017): Transition einer projektbasierten

Produktentwicklungsorganisation in ein agiles Cluster – ein Werkstattbericht. In

Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M.

(Hrsg.): Projektmanagement und Vorgehensmodelle 2017: Die Spannung zwischen dem

Prozess und den Menschen im Projekt. LNI-Band P-276, Gesellschaft für Informatik, S.

99–110, 2017.

30 Larissa Koch de Souza et al.

[Be01] Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Fowler, M.; Grenning, J.;

High-smith, J.; Hunt, A.; Jeffries, R.; Kern, J.; Marick, B.; Martin, R.; Mellor, S.;

Schwaber, K.; Sutherland, J.; Thomas, D.: Manifesto for Agile Software Development.

https://agilemanifesto.org/. 2001.

[Bl19] Blust, M.: Methoden, Chancen und Risiken hybrider

Projektmanagementvorgehensmodelle. In Linssen, O.; Mikusz, M.; Yigitbas, E.;

Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Kuhrmann, M.; Gesellschaft für Informatik

(Hrsg.): Projektmanagement und Vorgehensmodelle 2019: Neue Vorgehensmodelle in

Projekten – Führung, Kulturen und Infrastrukturen im Wandel. LNI-Band P-298,

Gesellschaft für Informatik, S. 69–82, 2019.

[BMF24] Bissinger, B.; Märtin, C.; Fellmann, M.: Auswirkungen von Remote Work auf die

Kommunikation und Zusammenarbeit von Scrum Teams sowie auf Scrum Master in der

Softwareentwicklung Operating Model als Schlüssel zum Erfolg. In Linssen, O.; Fazal-

Baqaie, M.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M.; Hanser, E.; Kalenborn,

A.; Gesellschaft für Informatik (Hrsg.): Projektmanagement und Vorgehensmodelle

2024: Neues Arbeiten in Projekten – Teamarbeit neu interpretiert, LNI-Band P-353,

Gesellschaft für Informatik, S. 17–34, 2024.

[BPM11] Baskerville, R.; Pries-Heje, J.; Madsen, S.: Post-agility: What follows a decade of

agility? Information and Software Technology, 53(5), S. 543–555, 2011.

[CA18] Certa, S. S.; Albayrak, C. A.: Eine hybride Vorgehensweise zur IT-

Projektportfolieplanung. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.;

Hanser, E.; Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der

Einfluss der Digitalisierung auf Projektmanagementmethoden und

Entwicklungsprozesse. LNI-Band P-286, Gesellschaft für Informatik, S. 135–145, 2018.

[Co09] Conboy, K.: Agility from First Principles: Reconstructing the Concept of Agility in

Information Systems Development. Information Systems Research 20(3), S. 329–354,

2009.

[Da14] Daut, P.: Agil in großen Organisationen: Eine neue Rolle im Scrum-Framework. In

Engstler, M.; Hanser, E.; Mikusz, M.; Herzwurm, G. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2014: Soziale Aspekte und Standardisierung. LNI-Band P-236,

Gesellschaft für Informatik, S. 99–109, 2014.

[Di17] Diebold, P.; Theobald, S.; Schmitt, A.; Schmidt, C.: Weg vom unvollständigen Scrum!

Hin zum vollständigeren „Scrum++". In Volland, A.; Engstler, M.; Fazal-Baqaie, M.;

Hanser, E.; Linssen, O.; Mikusz, M. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2017: Die Spannung zwischen dem Prozess und den Menschen im

Projekt. LNI-Band P-276, Gesellschaft für Informatik, S. 25–34, 2017.

[DKZ15] Diebold, P.; Küpper, S.; Zehler, T.: Nachhaltige Agile Transition: Symbiose von

technischer und kultureller Agilität. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2015:

Hybride Projektstrukturen erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für

Informatik, S. 121–126, 2015.

Wege zur Post-Agilität 31

[DS19] Diebold, P.; Simon, F.: Compliance: Umgang mit dem agilen Feind!? In Linssen, O.;

Mikusz, M.; Yigitbas, E.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Kuhrmann, M.;

Gesellschaft für Informatik (Hrsg.): Projektmanagement und Vorgehensmodelle 2019:

Neue Vorgehensmodelle in Projekten – Führung, Kulturen und Infrastrukturen im

Wandel. LNI-Band P-298, Gesellschaft für Informatik, S. 45–55, 2019.

[Fi18] Fischer, J.; Schönberg, C.; Breisig, T.; Winter, A.: Agilität in nicht-agilen Unternehmen.

In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.

(Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der Einfluss der

Digitalisierung auf Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band

P-286, Gesellschaft für Informatik, S. 195–200, 2018.

[FSH14] Fazal-Baqaie, M.; Sauer, S.; Heuft, T.: Agile entwicklung mit on- und offshore-partnern

- methodenverbesserung in der praxis. In Engstler, M.; Hanser, E.; Mikusz, M.;

Herzwurm, G. (Hrsg.): Projektmanagement und Vorgehensmodelle 2014: Soziale

Aspekte und Standardisierung. LNI-Band P-236, Gesellschaft für Informatik, S. 59–69,

2014.

[Ga18] Gampfer, F.: Managing Enterprise Architecture in Agile Environments. In Mikusz, M.;

Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2018: Der Einfluss der Digitalisierung auf

Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band P-286,

Gesellschaft für Informatik, S. 201–206, 2018.

[Gi22] Gill, K. S.; Eden, L.; Sengül, Ö.; Neumann, M.; Linke, L.: Agile Software-Entwicklung

& Remote Work: Auswirkungen auf die Interaktion und Autonomie agiler Teams. In

Fazal-Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M.;

Kalenborn, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2022: Virtuelle

Zusammenarbeit und verlorene Kulturen? LNI Band P-327, Gesellschaft für Informatik,

S. 37–47, 2022.

[Gö23] Göritz, L.; Kochon, E.; Beinke, J. H.; Pender, H.; Thomas, O.: From DevOps to

TeachOps: An Agile Approach for Instructional Design. In Kalenborn, A.; Fazal-

Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2023: Nachhaltige IT-Projekte. LNI-Band

P340, Gesellschaft für Informatik, S. 87–99, 2023.

[Gr17] Grünewald, C.: Agilität in Produktinnovationsprojekten mittelständischer

Unternehmen. In Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.;

Mikusz, M. (Hrsg.): Projektmanagement und Vorgehensmodelle 2017: Die Spannung

zwischen dem Prozess und den Menschen im Projekt. LNI-Band P-276, Gesellschaft für

Informatik, S. 173–186, 2017.

[Gr23] Greb, T.: Mehr Nachhaltigkeit in Projekten, Unternehmen und Gesellschaft durch

Virtualisierung. In Kalenborn, A.; Fazal-Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas,

E.; Engstler, M.; Randecker, L.; Heinzel, V.; Bertram, M.; Gesellschaft für Informatik

(Hrsg.): Projektmanagement und Vorgehensmodelle 2023: Nachhaltige IT-Projekte.

LNI-Band P340, Gesellschaft für Informatik, S. 101–111, 2023.

[GT19] Guckenbiehl, P.; Theobald, S.: Assessment of Agile Culture. In Linssen, O.; Mikusz,

M.; Yigitbas, E.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Kuhrmann, M.;

Gesellschaft für Informatik (Hrsg.): Projektmanagement und Vorgehensmodelle 2019:

Neue Vorgehensmodelle in Projekten – Führung, Kulturen und Infrastrukturen im

Wandel. LNI-Band P-298, Gesellschaft für Informatik, S. 165–176, 2019.

32 Larissa Koch de Souza et al.

[Gu23] Guckenbiehl, P.; Krieg, A.; Brandt, S.; Theobald, S.: On Agile Leadership and Project

Sustainability. In Kalenborn, A.; Fazal-Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas,

E.; Engstler, M.; Bertram, M. (Hrsg.): Projektmanagement und Vorgehensmodelle 2023:

Nachhaltige IT-Projekte. LNI-Band P340, Gesellschaft für Informatik, S. 113–123,

2023.

[He15] Hennen, C.; Kalenborn, A.; Stadlbauer, S.; Timm, I.: Systematisierung der Auswahl von

Vorgehensmodellen durch Kennzahlen. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2015:

Hybride Projektstrukturen erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für

Informatik, S. 55–65, 2015.

[HL19] Hüsselmann, C.; Leyendecker, B.: Lean-Prinzipien in Projekten – Grundlagen des Lean

Project Managements. In Linssen, O.; Mikusz, M.; Yigitbas, E.; Volland, A.; Engstler,

M.; Fazal-Baqaie, M.; Kuhrmann, M.; Gesellschaft für Informatik (Hrsg.):

Projektmanagement und Vorgehensmodelle 2019: Neue Vorgehensmodelle in Projekten

– Führung, Kulturen und Infrastrukturen im Wandel. LNI-Band P-298, Gesellschaft für

Informatik, S. 221–235, 2019.

[HK14] Hilmer, S.; Krieg, A.: Standardisierung vs. Kultur: Klassisches und agiles

Projektmanagement im Vergleich. In Engstler, M.; Hanser, E.; Mikusz, M.; Herzwurm,

G. (Hrsg.): Projektmanagement und Vorgehensmodelle 2014: Soziale Aspekte und

Standardisierung. LNI-Band P-236, Gesellschaft für Informatik, S. 47–57, 2014.

[Ho20] Hofert, S.: Führen in die postagile Zukunft. In Hofert,  S. (Hrsg.): Führen in die postagile

Zukunft: Die Arbeitswelt sinnvoll gestalten und mutig vorangehen. Springer Gabler, 

2020.

[HS18] Hörner, S.; Schmitt A.: Implementierung agiler Praktiken in Geschäftsprozesse. In

Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.

(Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der Einfluss der

Digitalisierung auf Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band

P-286, Gesellschaft für Informatik, S. 169–173, 2018.

[HS24] Hilmer, S.; Stapel, H.: Das Prinzip „Agil-agil-werden“ – Die Anwendung agiler Denk-

und Arbeitsweisen in agilen Veränderungen. In Linssen, O.; Fazal-Baqaie, M.; Volland,

A.; Yigitbas, E.; Engstler, M.; Bertram, M.; Hanser, E.; Kalenborn, A.; Gesellschaft für

Informatik (Hrsg.): Projektmanagement und Vorgehensmodelle 2024: Neues Arbeiten

in Projekten – Teamarbeit neu interpretiert, LNI-Band P-353, Gesellschaft für

Informatik, S. 137–147, 2024.

[KL14] Kuhrmann, M.; Linssen, O.: Welche Vorgehensmodelle nutzt Deutschland? In Engstler,

M.; Hanser, E.; Mikusz, M.; Herzwurm, G. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2014: Soziale Aspekte und Standardisierung. LNI-Band P-236,

Gesellschaft für Informatik, S. 17–32, 2014.

[Kl17] Klünder, J.; Schmitt, A.; Hohl, P.; Schneider, K.: Fake News: Simply Agile. In Volland,

A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2017: Die Spannung zwischen dem Prozess

und den Menschen im Projekt. LNI-Band P-276, Gesellschaft für Informatik, S. 187–

192, 2017.

Wege zur Post-Agilität 33

[Kn15] Kneuper, R.: Klassische und agile Vorgehensmodelle – Ein historischer Überblick. In

Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2015: Hybride Projektstrukturen

erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für Informatik, S. 29–37, 2015.

[Ko23] Koch de Souza, L.: Implementierung des Circular Economy Konzepts bei

ITDienstleistern: Eine Systematische Literaturrecherche. In Kalenborn, A.; Fazal-

Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2023: Nachhaltige IT-Projekte. LNI-Band

P340, Gesellschaft für Informatik, S. 217–232, 2023.

[Kr15] Krieg, A.: Bierdeckelskizzen - Scrum ist leicht aber nicht einfach. In Engstler, M.; Fazal-

Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2015: Hybride Projektstrukturen erfolgreich umsetzen. LNI-Band P-

250, Gesellschaft für Informatik, S. 107–117, 2015.

[Kr16] Krieg, A.: Reifegradmodell für agile Unternehmensentwicklung (Agile Maturity

Model). In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M.;

Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2016: Arbeiten in

hybriden Projekten: Das Sowohl-als-auch von Stabilität und Dynamik. LNI-Band P-263,

Gesellschaft für Informatik, S. 161–169, 2016.

[Kr17] Krieg, A.: Agiler Projektleiter – Vermittler und Moderator im hybriden Projektumfeld.

In Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M.

(Hrsg.): Projektmanagement und Vorgehensmodelle 2017: Die Spannung zwischen dem

Prozess und den Menschen im Projekt. LNI-Band P-276, Gesellschaft für Informatik, S.

61–70, 2017.

[Kr19] Krieg, A.: Agile Organisationsentwicklung und agiles Change-Management. In Linssen,

O.; Mikusz, M.; Yigitbas, E.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Kuhrmann,

M.; Gesellschaft für Informatik (Hrsg.): Projektmanagement und Vorgehensmodelle

2019: Neue Vorgehensmodelle in Projekten – Führung, Kulturen und Infrastrukturen im

Wandel. LNI-Band P-298, Gesellschaft für Informatik, S. 253–261, 2019.

[KS18] Kurtz, K.; Sauer, J.: Auswirkungen des Einsatzes hybrider Methoden auf die

Projektsteuerung. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser,

E.; Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der Einfluss

der Digitalisierung auf Projektmanagementmethoden und Entwicklungsprozesse. LNI-

Band P-286, Gesellschaft für Informatik, S. 73–83, 2018.

[KTK18] Krieg, A.; Theobald, S.; Küpper, S.: Erfolgreiche agile Projekte benötigen ein agiles

Umfeld. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der Einfluss der

Digitalisierung auf Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band

P-286, Gesellschaft für Informatik, S. 217–222, 2018.

[Ku16] Kuhrmann, M.; Münch, J.; Diebold, P.; Linssen, O.; Prause, C. R.: On the use of hybrid

development approaches in software and systems development: construction and test of

the HELENA survey. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.;

Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2016:

Arbeiten in hybriden Projekten: Das Sowohl-als-auch von Stabilität und Dynamik. LNI-

Band P-263, Gesellschaft für Informatik, S. 59–68, 2016.

34 Larissa Koch de Souza et al.

[Kü17] Küpper, S.; Kuhrmann, M.; Wiatrok, M.; Andelfinger, U.; Rausch, A.: Is There a

Blueprint for Building an Agile Culture?. In Volland, A.; Engstler, M.; Fazal-Baqaie,

M.; Hanser, E.; Linssen, O.; Mikusz, M. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2017: Die Spannung zwischen dem Prozess und den Menschen im

Projekt. LNI-Band P-276, Gesellschaft für Informatik, S. 111–128, 2017.

[KZ14] Kraft, B.; Zöll, A.: Von der Langstrecke zum Sprint - Agile Methoden in traditionellen

Unternehmen. In Engstler, M.; Hanser, E.; Mikusz, M.; Herzwurm, G. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2014: Soziale Aspekte und

Standardisierung. LNI-Band P-236, Gesellschaft für Informatik, S. 35–45, 2014.

[Li14] Liebig, H. C. (2014): Praktische Umsetzung eines internationalen Web-Relaunchs mit

Hilfe einer hybriden Projektmethodik. In Engstler, M.; Hanser, E.; Mikusz, M.;

Herzwurm, G. (Hrsg.): Projektmanagement und Vorgehensmodelle 2014: Soziale

Aspekte und Standardisierung. LNI-Band P-236, Gesellschaft für Informatik, S. 129–

134, 2014.

[LKM15] Leppanen, M.; Kilamo, T.; Mikkonen, T.: Towards Post-Agile Development Practices

through Productized Development Infrastructure. In 2015 IEEE/ACM 2nd International

Workshop on Rapid Continuous Software Engineering (RCoSE 2015): Florence, Italy,

23 May 2015, S. 34–40. IEEE, 2015.

[Mü15] Müller, W.: Hybrid ist Pflicht - mit Ultimate/Reliable Scrum und Critical Chain zu einer

hochskalierbaren agilen Projektorganisation. In Engstler, M.; Fazal-Baqaie, M.; Hanser,

E.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2015:

Hybride Projektstrukturen erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für

Informatik, S. 93–106, 2015.

[Ne18] Neu, C.; Greff, T.; Blust, M.; Seel, C.; Wert, D.: Hybrides Projektmanagement in KMU

mittels adaptiver Softwarelösungen - Konzeption eines kollaborativen und holistischen

Self-Service Frameworks. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.;

Hanser, E.; Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der

Einfluss der Digitalisierung auf Projektmanagementmethoden und

Entwicklungsprozesse. LNI-Band P-286, Gesellschaft für Informatik, S. 103–111, 2018.

[NMK16] Nuhn, H. F. R.; Martini, J.; Kostron, A.: Hybride Strukturen in der Automobilindustrie

- Studie zu Agilen Praktiken in Forschungs- und Entwicklungsprozessen. In Engstler,

M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M.; Volland, A. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2016: Arbeiten in hybriden Projekten: Das

Sowohl-als-auch von Stabilität und Dynamik. LNI-Band P-263, Gesellschaft für

Informatik, S. 29–36, 2016.

[ÖD16] Özcan, G.; Drescher, A.: Hybride Vorgehensmodelle und Lean Methoden in global

verteilten Produktentwicklungsprojekten. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Linssen, O.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2016: Arbeiten in hybriden Projekten: Das Sowohl-als-auch von

Stabilität und Dynamik. LNI-Band P-263, Gesellschaft für Informatik, S. 153–159,

2016.

[Or19] O’Reilly, B.: No More Snake Oil: Architecting Agility through Antifragility. Procedia

Computer Science, 151, S. 884–890, 2019.

Wege zur Post-Agilität 35

[Pe15] Petrik, D.: Hybride Vorgehensmodelle in der Versionserstellung - ein Praxisbeitrag. In

Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2015: Hybride Projektstrukturen

erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für Informatik, S. 75–91, 2015.

[Pr18] Przybilla, L.; Schreieck, M.; Klinker, K.; Pflügler, C.; Wiesche, M.; Krcmar, H.:

Combining Design Thinking and Agile Development to Master Highly Innovative IT

Projects. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.;

Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der Einfluss der

Digitalisierung auf Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band

P-286, Gesellschaft für Informatik, S. 113–124, 2018.

[RE24] Randecker, L.; Engstler, M.: Partielle Rückkehr ins Büro – Zeitgemäße

Arbeitsplatzgestaltung. In Fazal-Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas, E.;

Engstler, M.; Bertram, M.; Hanser, E.; Kalenborn, A.; Gesellschaft für Informatik

(Hrsg.): Projektmanagement und Vorgehensmodelle 2024: Neues Arbeiten in

Projekten—Teamarbeit neu interpretiert. LNI-Band P-353, Gesellschaft für Informatik,

123-134, 2024.

[REH23] Randecker, L.; Engstler, M.; Heinzel, V.: Reifegrad Nachhaltigkeit – Literatur Review

vorhandener Modelle und Transfer auf IT-Projekte. In Kalenborn, A.; Fazal-Baqaie, M.;

Linssen, O.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2023: Nachhaltige IT-Projekte. LNI-Band

P340, Gesellschaft für Informatik, S. 137–148, 2023.

[RW14] Roelofsen, R.; Wilczek, S.: Markup-basiertes Spezifikations- und

Anforderungsmanagement in agilen Softwareprojekten. In Engstler, M.; Hanser, E.;

Mikusz, M.; Herzwurm, G. (Hrsg.): Projektmanagement und Vorgehensmodelle 2014:

Soziale Aspekte und Standardisierung. LNI-Band P-236, Gesellschaft für Informatik, S.

143–152, 2014.

[SB19] Siegeris, J.; Barke, H.: Agile for agile - new ideas for the transformation of student

projects. In Linssen, O.; Mikusz, M.; Yigitbas, E.; Volland, A.; Engstler, M.; Fazal-

Baqaie, M.; Kuhrmann, M.; Gesellschaft für Informatik (Hrsg.): Projektmanagement

und Vorgehensmodelle 2019: Neue Vorgehensmodelle in Projekten – Führung,

Kulturen und Infrastrukturen im Wandel. LNI-Band P-298, Gesellschaft für Informatik,

S. 151–164, 2019.

[Sc15] Schopka, K.: Controlling von hybriden Projekten - Herausforderungen und Chancen. In

Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.):

Projektmanagement und Vorgehensmodelle 2015: Hybride Projektstrukturen

erfolgreich umsetzen. LNI-Band P-250, Gesellschaft für Informatik, S. 183–187, 2015.

[SH15] Schockert, S.; Herzwurm, H.: Das Business setzt die Prioritäten?! In Engstler, M.; Fazal-

Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A.; Gesellschaft für Informatik (Hrsg.):

Projektmanagement und Vorgehensmodelle 2015: Hybride Projektstrukturen

erfolgreich umsetzen. LNI-Band P250, Gesellschaft für Informatik, S. 151–167, 2015.

[SKN18] Sellmann, M.; Kneuper, R.; Neunert, T.: Agile- klassisch- hbyrid: Ergebnisse einer

Expertenbefragung. In Mikusz, M.; Volland, A.; Engstler, M.; Fazal-Baqaie, M.;

Hanser, E.; Linssen, O. (Hrsg.): Projektmanagement und Vorgehensmodelle 2018: Der

Einfluss der Digitalisierung auf Projektmanagementmethoden und

Entwicklungsprozesse. LNI-Band P-286, Gesellschaft für Informatik, S. 85–94, 2018.

36 Larissa Koch de Souza et al.

[SRE15] Süptitz, T.; Ruppert, F.; Eymann, T.: IT-systementwicklungsprojekte der öffentlichen

hand: der einfluss des vergaberechts auf die verwendung agiler methoden. In Engstler,

M.; Fazal-Baqaie, M.; Hanser, E.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement

und Vorgehensmodelle 2015: Hybride Projektstrukturen erfolgreich umsetzen. LNI-

Band P-250, Gesellschaft für Informatik, S. 67–74, 2015.

[SS22] Scholz, G.; Schuster, T.: ProPhi: Eine neue Methode zur Auswahl einer passenden

Projektmanagementphilosophie. In Fazal-Baqaie, M.; Linssen, O.; Volland, A.;

Yigitbas, E.; Engstler, M.; Bertram, M.; Kalenborn, A. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2022: Virtuelle Zusammenarbeit und verlorene Kulturen? LNI Band

P-327, Gesellschaft für Informatik, S. 141–153, 2022.

[Ti18] Timinger, H.: Agilität in traditionellen Projekten. In Mikusz, M.; Volland, A.; Engstler,

M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2018: Der Einfluss der Digitalisierung auf

Projektmanagementmethoden und Entwicklungsprozesse. LNI-Band P-286,

Gesellschaft für Informatik, S. 227–230, 2018.

[TZK16] Trahasch, S.; Zimmer, M.; Krawatzeck, R.: Agile Business Intelligence als Beispiel für

ein domänenspezifisch angepasstes Vorgehensmodell. In Engstler, M.; Fazal-Baqaie,

M.; Hanser, E.; Linssen, O.; Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und

Vorgehensmodelle 2016: Arbeiten in hybriden Projekten: Das Sowohl-als-auch von

Stabilität und Dynamik. LNI-Band P-263, Gesellschaft für Informatik, S. 187–195,

2016.

[VHH24] Vavra, C.; Heizmann, J.; Hanser, E.: Von der Theorie zur Praxis: Implementierung des

Meta Agile Process Model zur Optimierung von Projektteams. In Fazal-Baqaie, M.;

Linssen, O.; Volland, A.; Yigitbas, E.; Engstler, M.; Bertram, M.; Hanser, E.;

Kalenborn, A.; Gesellschaft für Informatik (Hrsg.): Projektmanagement und

Vorgehensmodelle 2024: Neues Arbeiten in Projekten—Teamarbeit neu interpretiert.

LNI-Band P-353, Gesellschaft für Informatik, S. 149–160, 2024.

[VS23] Vogl, U.; Siegle, M.: Scaled Agile: Toolgestützte Echtzeitplausibilisierung des PI-

Planning. In Kalenborn, A.; Fazal-Baqaie, M.; Linssen, O.; Volland, A.; Yigitbas, E.;

Engstler, M.; Bertram, M. (Hrsg.): Projektmanagement und Vorgehensmodelle 2023:

Nachhaltige IT-Projekte. LNI-Band P340, Gesellschaft für Informatik, S. 161–168,

2023.

[We17] Weßel, C.: Vom „Kam anders“ – Agilität in konservativen Unternehmen entdecken. In

Volland, A.; Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.; Mikusz, M.

(Hrsg.): Projektmanagement und Vorgehensmodelle 2017: Die Spannung zwischen dem

Prozess und den Menschen im Projekt. LNI-Band P-276, Gesellschaft für Informatik, S.

71–80, 2017.

[WH16] Weingärtner, T.; Hofstetter, J.: Minimum Viable Project - Die Zukunft des agilen

Projektmanagements. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.;

Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2016:

Arbeiten in hybriden Projekten: Das Sowohl-als-auch von Stabilität und Dynamik. LNI-

Band P-263, Gesellschaft für Informatik, S. 147–152, 2016.

Wege zur Post-Agilität 37

[WVM16] Weinrich, T.; Volland, A.; Muntermann, J.: Herausforderungen bei der Einführung

agiler Vorgehensweisen. In Engstler, M.; Fazal-Baqaie, M.; Hanser, E.; Linssen, O.;

Mikusz, M.; Volland, A. (Hrsg.): Projektmanagement und Vorgehensmodelle 2016:

Arbeiten in hybriden Projekten: Das Sowohl-als-auch von Stabilität und Dynamik. LNI-

Band P-263, Gesellschaft für Informatik, S. 79–92, 2016.

Anhang

Auswertung der Literatur

Autoren Agilitätsverständnis Post-Agile Impulse

Agil positiv

oder

kritisch?

PVM 2014 – Soziale Aspekte und Standardisierung

[Da14]

Scrum. Agilität „kleiner“

Organisationen auf große

anwenden

Lean-Prinzipien, Story

Owner ergänzend zu

Product Owner

Positiv und

kritisch

[FSH14]

Agile Prinzipien mit

Gegebenheiten in

Unternehmen vereinbaren,

inkrementelle

Methodenverbesserung

Modulares Konzept mit

Bausteinen für spezielle

Bedingungen

Positiv und

kritisch

[HK14]

Projektkultur als Lückenfüller

für nicht vorhandene

Standardisierung

Modernes PM sollte weder

rein klassische noch rein

agile Sicht einnehmen

Positiv

[KL14]

Agile Ansätze sind in der

Praxis verbreitet, jedoch nicht

so sehr wie vermutet

Wenig systematische

Auswahl und Tailoring des

gewählten Modells

Neutral

[KZ14]

Fokus auf inhaltlich und

soziale Aspekte bei neuer

Rollenprägung

Lean, Kombination

klassischer und agiler

Ansätze, Synthese aus RUP

und Scrum: AGSMagile,

dem Kunden Vorteile agiler

Arbeit aufzeigen, um

klassische Steuerungs-

instrumente zu vermeiden

Positiv

[Li14]

Komplexe, internationale IT-

Projekte können von hybrider

Projektmethodik profitieren

Einbindung externer

Unternehmen in agile

Methoden sowie

Entscheidungsfindung sind

herausfordernd, Moral

Hazard-Problematik

Positiv und

kritisch

[RW14]

Agile Softwareprojekte

benötigen spezielles

Eigene Plattform zur

Erstellung von

Positiv und

kritisch

38 Larissa Koch de Souza et al.

Management von

Anforderungen und

Spezifikation

Spezifikationen mit

individueller Berichts-

Generation je nach

Stakeholder: agileSpecs

PVM 2015 – Hybride Projektstrukturen erfolgreich umsetzen

[AE15]

Hybride Vorgehensmodelle

als Kombination aus

klassischen und agilen

Methoden, agile Methoden

gelten als hochflexibel,

transparente Vorgehensweisen

Flexible Requirements

Engineering-Methoden statt

Fachkonzept oder

Wasserfallmodell mit

Iterationen, Quality Gates,

Fortschrittskontrolle

Positiv

[DKZ15]

Anzustrebende Symbiose

zwischen technischer und

kultureller Agilität

Technische Agilität nimmt

führende Rolle ein,

kulturelle Agilität ist

ebenfalls erforderlich, um

Entwicklungsvorgehen ggü.

Agilität anzupassen

Positiv

[He15]

Vorstellung von 53

Kennzahlen zur Auswahl

eines (agilen)

Vorgehensmodells

Bei Priorität von Zeit vs.

Umfang ist eine agile

Vorgehensweise zu

bevorzugen

Neutral

[Kn15]

Prototyping, Boehms

Spiralmodell, Rapid

Application Development,

XP, DSDM, FDD, Lean

Production. Agile Manifesto

Hybrides Vorgehen bspw.

über Kanban und DevOps Positiv

[Kr15]

Scrum als schnelles und

flexibles Rahmenwerk, Agile

Manifesto und Scrum Guide

Schrittweise Einführung

empfohlen, agiler Coach

zur Einführung

Positiv

[Mü15]

Critical Chain

Projektmanagement, agile

Methoden können keine

Lieferumfänge zusichern und

sind zu langsam

Multitasking führt zu

Mehraufwand, Puffer

identifizieren, um

Projektlaufzeit zu

verkürzen, Reliable/

Ultimate Scrum,

Skalierbarkeit noch

unzureichend, Eliminierung

von Sprints durch Aufteilen

von Stories in Tasks

Positiv und

kritisch

[Pe15] XP und Scrum

Hybrides

Projektmanagement ist am

besten skalierbar

Positiv und

kritisch

[Sc15]

Aufhebung der strikten

Trennung zwischen

Beyond-, Better- und

Advanced- Budgeting,

Positiv

Wege zur Post-Agilität 39

Planungsphase und

Umsetzungsphase zugunsten

ergebnisgetriebener, zeitlich

überschaubarer Sprints mit

schnell überprüfbaren

Ergebnissen

inhalts- und

ergebnisorientiertes

Controlling, Verringerung

der Detailtiefe in Planung,

Rollierende Forecasts,

nicht-monetäre Größen zur

Planung sowie Output-

orientierte Festlegung von

Zielen und Plänen

[SH15]

Priorisierung ist wenig

systematisch, adhoc und ohne

Berücksichtigung von

Nutzeffekten für Kunden

Verankerung von

Dreiteilung aus Problemen,

Lösungen und

Anforderungen, Continuous

Quality Function

Development als

inkrementelle

Matrixerstellung und

Maximum Value Table

Positiv und

kritisch

[SRE15]

V-Modell XT bietet Tailoring-

Möglichkeiten zur Integration

agiler Methoden, Grenzen

durch Vergaberecht mit

erschöpfender

Leistungsbeschreibung

Begrenzung auf funktionale

Leistungsbeschreibung

sowie dreistufiges

Vergabeverfahren zur

Reduktion des

Planungsaufwands und

Steigerung der

Planungsqualität

Positiv und

kritisch

PVM 2016 – Arbeiten in hybriden Projekten

[Al16]

Agile Vorgehensmodellen wie

Scrum und Kanban

(kein post-agiler Impuls) Neutral

[Kr16] Agiles Manifest

Herausforderungen wie

Bewältigung von

Komplexität,

Flexibilisierung von

Prozessen und

Wertschöpfungsketten

Positiv und

kritisch

[Ku16]

Agilität ist v.a. in Ent-

wicklungsprojekten zu finden

(kein post-agiler Impuls) Positiv

[NMK16]

Scrum; Agilität vornehmlich

in Softwareentwicklungs-

projekten zu finden, nicht in

Produkt-Entwicklung

(kein post-agiler Impuls) Positiv

[ÖD16]

Agile Methoden wie Scrum

sind gegenüber klassischen

Hybride Modelle, Bedarf

zur Entwicklung einer

Positiv und

kritisch

40 Larissa Koch de Souza et al.

Methoden flexibler,

transparente Vorgehensweise

für noch nicht eindeutig

definierte Problemstellungen

ganzheitlichen Methode zur

flexiblen Vernetzung von

Geschäftsprozessen in

hybriden Produktent-

wicklungsprojekten, Petri-

Netze, Lean Management

[TZK16]

Vorhersehbare und

unvorhersehbare

Anforderungen in Bezug auf

Funktionalität oder den Inhalt

einer BI-Lösung effizient in

einem vorgegebenen

Zeitrahmen in angemessener

Qualität abzubilden

(kein post-agiler Impuls) Positiv

[WH16]

Agile Manifest, iterativer

Lernprozess, Build-Measure-

Learn

Minimum Viable Project

einführen

Positiv und

kritisch

[WVM16]

Agile Manifest, XP, lean

software development,

feature-driven development,

schnelle Veränderungen,

proaktiv oder reaktiv und aus

Veränderungen lernen

Verständnis für agile

Vorgehensmodelle

Positiv und

kritisch

PVM 2017 – Die Spannung zwischen dem Prozess und Mensch im Projekt

[Al17]

Scrum XP, Feature Driven

Development

(kein post-agiler Impuls) Neutral

[BJ17]

Scrum, LeSS, kultureller

Wandel, Selbstorganisation,

kontinuierliches Lernen

Nicht top-down vorgeben,

Iteratives vorgehen statt

Reißbrett-Konzept,

permanenter Wandel

Positiv

[Di17] Scrum, modularer Rahmen

Ergänzung von Scrum++ ,

ScrumBan, Scrum+XP

Positiv

[Gr17]

Agilität als Mittel zur

Bewältigung von Komplexität

und zur Förderung von

Innovationskultur

Adaptive und hybride

Modelle Positiv

[Kl17]

Oftmals fälschlicherweise als

reine Scrum-Anwendung

verstanden

Kulturelle und menschliche

Aspekte statt

Methodenhörigkeit

Kritisch

[Kr17]

Flexible Reaktion auf

Komplexität

Hybride Vorgehensmodelle Positiv

[Kü17]

Agilität als kulturelles

Phänomen, being vs. doing

agile

Individuelle,

kontextabhängige

Transformation statt

Neutral

Wege zur Post-Agilität 41

Standardvorgaben

[We17]

Projektnatur liegt im hybriden

und konservative

Unternehmen tun sich schwer

mit Agilität

Wertschätzende Erkundung

bezüglich des Umfelds und

der Umsetzung von Agilität

für agile Ansätze bei nicht-

agilen Unternehmen

Neutral

PVM 2018 – Der Einfluss der Digitalisierung auf Projektmanagementmethoden

und Entwicklungsprozesse

[Bä18]

Organisationskulturen und

agile Transformationen sind

individuell, weswegen es

erhöhte Involvierung von

aktiver, interner

Kommunikation bedarf zur

Unterstützung agiler

Praktiken, Mitarbeitende und

Führungskräfte müssen

Agilität unterstützen

Interne Kommunikation

muss agile Transformation

aktiv unterstützen,

Stakeholder kennen und

Mitarbeiter durch

interaktive Kanäle

einbinden

Positiv und

kritisch

[CA18]

IT-Projektportfolio bislang

mit Fokus auf klassischen

Vorgehensmodellen und im

Konflikt zur flexiblen Agilität

da keine Langfristigkeit der

Meilensteine

Durch kürzere

Planungszeiträume im

Portfoliomanagement

Kompromiss zur agilen

Planbarkeit und Ziel des

hybriden Portfolio-

managements,

kontextsensitiv anpassen

Positiv und

kritisch

[Fi18]

Agilität steht im Konflikt zu

organisatorischen und

regulatorischen Vorschriften,

zur Vereinigung müssen

Rollen ergänzt werden um

Schnittstelle von nicht-agilem

Umfeld und agilen Vorgaben

zu bilden (bspw. Personal oder

Fürsorgepflicht und Budget)

Agilität ist auch für

klassische Umfelder

anwendbar, jedoch unter

Berücksichtigung von

Anpassungen/Ergänzungen

Positiv

[Ga18]

Enterprise Architecture im

agilen Kontext ist anzupassen

und dezentral zwischen

Architekt und Team

aufzusetzen

Übertrag von Agilität auf

Enterprise Archtiecture

bedarf Anpassung des

Umfelds an die

Dezentralisierung

Positiv

[HS18]

Agilität zur Ermöglichung

flexibler Geschäftsprozesse

über Softwareentwicklung

hinaus

Übertrag agiler Praktiken

auf andere Bereiche (bspw.

über BizOps statt DevOps)

Positiv

42 Larissa Koch de Souza et al.

[Ne18]

Agile Modelle zu komplex für

KMU, teils hybride Formen

leichter umsetzbar

Vorschlag eines hybriden

Self-Service Frameworks

unter Berücksichtigung von

Projektkontext und

Situation

Kritisch

[KS18]

Hybride Methoden als

häufigste Form der

Vorgehensmodelle, primär

neue Vorteile dadurch jedoch

auch erwartete Nachteile

(bspw. Mehraufwand), teils

keine Kombination aus agil

mit klassisch möglich,

Skalierung aber nur durch

Kombination

Wahl der (hybriden) Form

muss abhängig gemacht

werden von Projekt, es

benötigt Erfahrung beider

einzeln Methoden sowie

transparente

Kommunikation durch

Führung bzgl.

Vorgehensweise

Positiv und

kritisch

[KTK18]

Agilität muss auf vollständiger

Organisationsebene umgesetzt

werden, dafür es benötigt ein

kooperatives, agiles Umfeld

Agilität nicht nur in

einzelnen (technischen)

Bereichen für Erfolg, agile

Kultur berücksichtigen

Positiv und

kritisch

[Pr18]

Agile Entwicklung ist zu

abhängig von Product Owner

statt Kunde für innovative IT,

was nur nützlich ist bei klarem

Projektziel und Lösungs-

implementierung aber nicht

wenn Lösung unklar ist

Kombination von Design

Thinking mit agilen

Praktiken, um Kunden- und

Menschenzentriert in

Projekten zu arbeiten

(bspw. exploratives Team-

Mindset stärken)

Kritisch

[SKN18]

Agilität besonders für unklare

Aufgaben und sich ändernde

Anforderungen, für

Planbarkeit jedoch klassische

Methoden nötig, hybrid bietet

Möglichkeit zur Verbindung

beider positiven Effekte aber

ggf. mit Mehraufwand und

Methodeneinbußungen

Grenzen zwischen den

Methoden (klassisch, agil,

hybrid) verschwimmen und

es herrscht Unsicherheit in

Praxis, man sollte sich auf

eine Form festlegen, Kultur,

Teams und Führung müssen

verstärkt betrachtet werden

Positiv und

kritisch

[Ti18]

Unterscheidung von agilem

Mindset/Kultur und agilen

Prozessen, ggf. hybride

Mischform zielführender

Hierarchische, planbasierte

Führung versus

Selbstbestimmung und

Eigenverantwortung in

agilen Prozessen als

Spannungsfeld, welches

aufgelöst werden muss

Positiv und

kritisch

Wege zur Post-Agilität 43

PVM 2019 – Neue Vorgehensmodelle in Projekten – Führung, Kulturen und

Infrastrukturen im Wandel

[Bl19]

Agilität steht in Konflikt zu

Planbarkeit, Langfristigkeit

und strukturierter Umsetzung,

Flexibilität und Kultur sollen

beibehalten werden

Hybride Vorgehensmodelle

bieten Lösung, langfristige

Planbarkeit und agile

Umsetzung sind zu

kombiniert, Risiko von

Dogmatismus

Positiv und

kritisch

[DS19]

Agilität kann auf verschiedene

Weisen beeinträchtigt werden

(„nicht können“ und „nicht

dürfen“, selten „nicht

wollen“). Umsetzung

einzelner agiler Module

zielführender für Erfolg

Betrachtung von

inkrementellen

Methodenbausteine für eine

Zielagilität im Rahmen der

Umgebung und

Anforderungen

Kritisch

[GT19]

Agilität in der Software-

entwicklung, agile Kultur und

agiles Mindset sind auf andere

Bereiche übertragbar

Fokus auf Kultur anstelle

auf Prozessveränderung,

ansonsten Agilität nicht

gesichert skalierbar

Kritisch

[HL19]

Agilität wird zunehmend

skaliert (SAFe, etc.), SCRUM

als Ansatz nicht vollständig

Lean Management

(Reduzierung auf das was

für Kunde Wert darstellt)

als Kompromiss, wenn agil

nicht vollständig alles

abbildet und klassisch zu

schwergewichtig ist

Kritisch

[Kr19]

Agilität wird umgesetzt über

agiles Change Management

entlang mehrerer

Veränderungsebenen, klares

Ziel, Vision und Top-

Management sind nötig

Skalierung nötig als

Weiterentwicklung, mehr

Agilität in Führung und

Management und mehr

Bedarf nach agilem Change

Management

Kritisch

[SB19]

Anwendung agiler Methoden

(SCRUM) auch für

studentische Projekte

Übertrag der Methode auf

andere Bereiche, Fokus auf

agilen Werte und

Kollaboration

Positiv

44 Larissa Koch de Souza et al.

PVM 2022 – Virtuelle Zusammenarbeit und verlorene Kulturen?

[Gi22]

Agilität im Remote Work

Umfeld vor allem über

digitale Kommunikationstools

ermöglicht, Team wird aber

eingeschränkt

Agilität im Rahmen von

Remote Work nicht

beeinträchtigt, aber

Interaktion und Team

Autonomie ist anzupassen

Positiv und

kritisch

[SS22]

Agilität nicht grundsätzlich

sondern je nach Umgebungs-

und Projektkontext auswählen

Einordnung in klassisches,

agiles und hybrides PM und

entsprechenden Fokus

Positiv und

kritisch

PVM 2023 – Nachhaltige IT-Projekte

[Gö23]

DevOps-Ansatz nicht nur für

Softwareagilität sondern in

Bildung und HR mittels

instruktionellem Design

Bedarf & Möglichkeit des

Übertrag von DevOps auf

andere Bereiche als

Softwareentwicklung

Positiv

[Gu23]

Synergien zwischen agiler

Führung und Nachhaltig-

keitsdimensionen für Agilität

Bedarf nach agiler Führung

und Nachhaltigkeit für

skalierbare Agilität

Positiv und

kritisch

[VS23]

Agilität steigend relevant,

Skalierung nötig (bspw. Über

Echtzeit-Plausibilisierung oder

SAFe-Framework)

Skalierbarkeit von agilen

Netzwerken und Teams

erhöhen über toolgestütztes

PI-Planning

Positiv und

kritisch

PVM 2024 – Neues Arbeiten in Projekten – Teamarbeit neu interpretiert

[BMF24]

Agilität über Scrum umsetzen

im Rahmen von Remote Work

funktioniert nicht gut

Agilität und Remote Work

muss in besseren Einklang

gebracht werden

Kritisch

[VHH24]

Fokus auf Teambildung durch

Meta-Agil-Process und

Ableitung von Projekttypen

Fokus weg von festen

Vorgehensmodellen und

stärker auf Team-

zusammensetzung

Neutral

[HS24]

(Klassische) Agilität gewinnt

an Relevanz und wird über

agile Methoden eingeführt

Agilität über agile

Methoden einführen und

Kultur verstärkt leben

Positiv

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 45

Zwischen Agilität und Resilienz: Spannungsfelder und das

Potenzial post-agiler Ansätze in digitalen Plattformen

Larissa Koch de Souza1 und Martin Engstler2

Abstract: In einer von Unsicherheit geprägten Wirtschaftslandschaft stehen digitale Plattformorga-

nisationen vor der Herausforderung, sowohl agil als auch resilient zu agieren. Diese Arbeit analysiert

durch eine Systematische Literaturrecherche (SLR) das Spannungsfeld zwischen Agilität und Resi-

lienz und hinterfragt, ob Resilienz als ergänzendes Ziel agiler Ansätze verstanden werden kann oder

ob sich die Konzepte fundamental widersprechen. Die Ergebnisse zeigen, dass Agilität und Resili-

enz in einem komplexen Wechselverhältnis stehen, das eine bewusste und kontextsensitive Priori-

sierung erfordert. Eine strukturierte Balance wird als Voraussetzung für den nachhaltigen Erfolg

digitaler Plattformen gesehen und liefert theoretische Ansatzpunkte, um post-agile Organisations-

formen gezielt weiterzuentwickeln und deren praktische Anwendung systematisch zu gestalten.

Keywords: Resilienz; Agilität; Post-Agilität; Organisationsmethoden; Digitale Plattformen

1 Einleitung

Der heutige Wirtschaftsmarkt ist von hoher Dynamik geprägt und wird durch eine zuneh-

mend volatile, unsichere, komplexe und ambige (VUCA-)Welt angetrieben [ZLZ25]. Glo-

bale Krisen und tiefgreifende Transformationen stellen Organisationen kontinuierlich vor

wachsende Herausforderungen. Immer mehr sehen sich Unternehmen mit Unsicherheiten

und unerwarteten Ereignissen konfrontiert [BA23; RC20; He25], deren Implikationen für

Entscheider schwer einschätzbar sind. Anpassungsfähigkeit wird zur zentralen Überle-

bensfähigkeit und klassische, starre Projektstrukturen stoßen dabei an ihre Grenzen

[Ho20]. Agilität hat sich daher bereits seit Jahren als vielversprechender Ansatz etabliert,

um flexibel, schnell und effizient auf nicht vorhersehbare Veränderungen reagieren zu

können [BH09]. Gleichzeitig wächst angesichts anhaltender Unsicherheit das Bedürfnis

nach Stabilität [LN21]. Organisationale Resilienz rückt als Antwort in den Fokus

[ZLZ25]. Zwischen Agilität und Resilienz entsteht dabei jedoch ein potentielles Span-

nungsfeld. Die Frage, ob und wie Agilität und Resilienz miteinander wirken oder sich

widersprechen, bleibt unbeantwortet, da sie in der Forschung meist isoliert betrachtet wer-

den [Gö20; BA23; Iy25; MM21]. Besonders relevant erscheint dies im Kontext digitaler

Plattformen. Als zentrale Infrastrukturform der digitalen Transformation orchestrieren sie

Märkte, vernetzen Akteure und ermöglichen neue Wertschöpfungsformen [LLL23]. Da-

mit bergen sie ein hohes Potenzial für Agilität und zugleich einen erhöhten Bedarf an

Resilienz [Ra18]. Jedoch gibt es bislang nur begrenzt Forschung zur Rolle digitaler Platt-

formen als Resilienztreiber [He25; Yu22] und zur gezielten kundenzentrierten Agilität von

Plattformen [HNP21].

1 Hochschule der Medien Stuttgart, Fakultät Information & Kommunikation, Nobelstr. 10, 70569 Stuttgart,

kochdesouza@hdm-stuttgart.de

2 Hochschule der Medien Stuttgart, Fakultät Information & Kommunikation, Nobelstr. 10, 70569 Stuttgart,

engstler@hdm-stuttgart.de

46 Larissa Koch de Souza und Martin Engstler

Vor diesem Hintergrund untersucht das vorliegende Paper die Beziehung zwischen Agili-

tät und Resilienz im Kontext digitaler Plattformen. Im Zentrum steht die Frage, ob Resili-

enz ein komplementäres Ziel agiler Prinzipien darstellen kann, oder ob sie ausschließlich

eine eigenständige, möglicherweise konfliktäre Organisationsform verkörpert. Daraus

ergibt sich die Überlegung, ob eine Weiterentwicklung in Richtung der Post-Agilität hilf-

reich oder gar notwendig ist, um beide Ansätze konstruktiv zu verbinden. Ziel dieser Stu-

die ist es, durch eine Systemtische Literaturrecherche (SLR), zentrale Spannungen, Wi-

dersprüche und Synergien zwischen Agilität und Resilienz herauszuarbeiten und erste Ge-

staltungsempfehlungen für Plattformorganisationen abzuleiten.

2 Einordnung von resilient-agilen Ansätzen für digitale Plattformen

Digitale Plattformen prägen zunehmend Wertschöpfungsformen von Organisationen im

Rahmen der digitalen Transformation [OBE24]. Als Form der technischen und sozialen

Infrastruktur orchestrieren sie Interaktionen zwischen verschiedenen Akteuren und er-

möglichen exponentielle Skalierung durch Netzwerkeffekte [Fa23; LLL23]. Mittels

Schnittstellen zwischen Dienstleistungen, Ressourcen und Nutzern ermöglichen sie ge-

teilte Dienste und Datenintegration und schaffen so neue, oft disruptive Geschäftsmodelle

[OBE24; Fa23]. Zunehmend nutzen Unternehmen digitale Plattformen nicht nur zur Op-

timierung bestehender Prozesse, sondern auch zur radikalen Erneuerung ihrer Strukturen

und zur strategischen Neuausrichtung [Pr24]. Allerdings gelingt es nicht allen Unterneh-

men, die Potenziale digitaler Plattformen auch für mehr Anpassungsfähigkeit erfolgreich

zu erschließen [Ra18]. Für einen erhöhten Wettbewerbsvorteil muss folglich die Fähigkeit

gestärkt werden, sie strukturell agil und resilient zugleich zu gestalten.

Bezüglich Agilität, findet sich der Ursprung der „modernen Organisationsform“ [Wi20]

im Manifest für Agile Softwareentwicklung [Be01] sowie den Ansätzen zur Erreichung

von Agilität im Produktionsbereich [SZ99]. Schnell entwickelten sich die ursprünglichen

Prinzipien rund um Grundüberzeugungen wie Zusammenarbeit, Kundeninteraktion und

reaktive Veränderung und agile Werte weiter [Bo20; QMN23]. So steht Agilität heutzu-

tage weitgefasst für organisationale Anpassungsfähigkeit, Flexibilität und Geschwindig-

keit [Iy25; BA23]. Der Ansatz der Agilität wurde mit Methoden wie Scrum konkretisiert.

Scrum ist ein dominierendes Rahmenwerk, das auf kurzen Zyklen (Sprints), klaren Rollen

und kollaborativen Events basiert [Ci25; Sa24; Bo20]. Die Versprechen agiler Ansätze

haben dazu geführt, dass Agilität heutzutage als Schlüsselkompetenz und etablierte Alter-

native zu traditionellen Planungs- und Organisationsmethoden gilt [Wa22], insbesondere

entlang dynamischer Veränderungen der digitalen Transformation [OBE24]. Allerdings

greift Agilität allein zu kurz, wenn Organisationen wie digitale Plattformbetreiber mit

langfristigen Krisen konfrontiert sind. Das Konzept der Resilienz gewinnt an Bedeutung.

Resilienz beschreibt die Fähigkeit der Widerstandskraft, wodurch auch in turbulenten Ent-

wicklungen und Stresssituationen eine strategische Bereitschaft vorhanden ist [BSM25;

Wi20]. Organisationale Resilienz geht darüber hinaus und bezeichnet konkret die Fähig-

keit von Organisationen, robuste und transformative Maßnahmen zu erbringen, um zügig

auf plötzliche Störungen reagieren zu können und unerwarteten Schocks standzuhalten

[ZLZ25; Un20]. Resilienz wird als zentrale Fähigkeit wahrgenommen [QMN23] und als

relevant für Dienstleister [LLL23] und Plattformunternehmen [Pr24] eingestuft.

Zwischen Agilität und Stabilität 47

In Anbetracht dieser doppelten Anforderung an digitale Plattformen gewinnen integrie-

rende Konzepte an Bedeutung, die Agilität und Resilienz als komplementäre Zielgrößen

vereinen [Li25; Gö20; Un20]. Solche Überlegungen, sowie weitere Anpassungsbedarfe

an die dynamische VUCA-Welt, münden in der Idee einer sogenannten Post-Agilität. Die

Vorsilbe „post“ verweist dabei nicht auf eine Zeit nach der Agilität, sondern auf eine Wei-

terentwicklung, die das Agile überwindet und in eine reflektierte, neue Richtung transfor-

miert [Ho20]. Post-Agilität wird jedoch bislang selten in der Literatur als solche angespro-

chen: So diskutiert [Kn17] den Bedarf eines post-agilen Ansatzes, welcher agile Methoden

um stärkere Team-Autonomität und hybride Praktiken ergänzt. [BPM11] sowie [LKM15]

sehen ebenfalls Entwicklungsbedarf bei der Agilität und betonen vor allem eine ver-

schärfte Berücksichtigung integrativer, mehrseitiger Zielstellungen auf andere Bereiche

der Organisationsplanung. Ob und wie sich (Post-)Agilität in den letzten Jahren weiter-

entwickelt hat, welches Potenzial dies für die Verbindung von Agilität und Resilienz birgt

und wie sich das auf digitale Plattformen übertragen ließe, bleibt bislang unerforscht.

3 Methode

Für die Analyse der im vorherigen Kapitel dargestellten Forschungslücke wurde die Me-

thode der Systematischen Literaturrecherche (SLR) gewählt, um bestehendes Wissen zu

sowohl Resilienz als auch Agilität zu synthetisieren. Die Durchführung der SLR folgte

dabei der Leitlinie von [Ki07] und umfasste folgende neun Schritte:

Die SLR wurde eingeleitet, indem die zentrale Forschungsfrage definiert wurde: Inwie-

fern beeinflussen sich Resilienzförderung und die Umsetzung agiler Prinzipien in digitalen

Plattformen und lässt sich darin ein Wandel in Richtung post-agiler Organisationsformen

erkennen? Die zentralen Konzepte Agilität, Resilienz, Post-Agilität und digitale Plattfor-

men wurden anschließend per Begriffsdefinition eingeführt, um Konsistenz und Klarheit

während der gesamten SLR zu gewährleisten. Die Definitionen wurden im Kurzumriss in

Kapitel 2 eingeführt und im Verlauf der SLR weiter verfeinert, wobei die endgültigen

Interpretationen im Ergebnisabschnitt unter 4.1 dargestellt werden. Basierend auf den de-

finierten Konzepten und Begriffen wurden im dritten Schritt relevante Schlüsselwörter

formuliert. Diese Schlüsselbegriffe bilden die konzeptionelle Grundlage als Themenberei-

che und umfassen: (Post-)Agilität, Resilienz und digitale Plattformen. Die Suche innerhalb

der SLR wurde anschließend unter Verwendung von sechs verschiedenen Datenbanken

durchgeführt: ScienceDirect, SpringerLink, ResearchGate, die Datenbanken der Univer-

sitätsbibliothek Stuttgart und der Hochschule der Medien Stuttgart (HdM) sowie die Da-

tenbank der Deutschen Nationalbibliothek (DNB). Die Suchstrings wurden dann im Rah-

men der Suchstrategie aus den vordefinierten Schlüsselbegriffen abgeleitet und mithilfe

boolescher Operatoren in den Datenbanken eingegeben. Folgender Suchstring wurde ver-

wendet: (‘Post-Agil*’ UND ‘Digitale Plattformen’) ODER (‘Post-Agil*’ UND ‘Resi-

lien*’) ODER (‘Digitale Plattformen’ UND ‘Agil*’) ODER (‘Digitale Plattformen’ UND

‘Resilien*’) ODER (‘Agil*’ UND ‘Resilien*’) Oder (‘Post-Agil*’)

Bezüglich der Definition von Ein- und Ausschlusskriterien wurden folgende Einschluss-

kriterien definiert: Die Literatur fokussiert mindestens einen der drei Schlüsselbegriffe,

wurde nach dem Jahr 2017 veröffentlicht und ist in englischer oder deutscher Sprache

48 Larissa Koch de Souza und Martin Engstler

verfasst. Studien wurden zudem ausgeschlossen, wenn sie keine konzeptionelle oder me-

thodische Relevanz aufwiesen. Der Screening-Prozess erfolgte in mehreren Stufen von

Ein- und Ausschlussentscheidungen und wurde mittels einem PRISMA-Flussdiagramm

[Pa21] durchgeführt und dargestellt (siehe Abb. 1). Zunächst wurden alle identifizierten

Einträge überprüft, um nach den formalen Basiskriterien zu filtern. In der anschließenden

thematischen Auswahlphase wurden Titel und Schlagwörter hinsichtlich ihrer Relevanz

für die Beantwortung der Forschungsfrage beurteilt. Anschließend wurden die Abstracts

geprüft, für eine tiefere thematische Eingrenzung. Schließlich wurde die Volltextanalyse

durchgeführt, wonach 33 Publikationen zur Aufnahme in die SLR berücksichtigt wurden.

Abb. 1: Screening-Prozess der SLR als PRISMA-Flussdiagramm

Im achten Schritt wurden die 33 ausgewählten Publikationen einer strukturierten Daten-

erhebung unterzogen. Zur systematischen Einordnung der Erkenntnisse jeder Publikation

im Hinblick auf die Forschungsfrage wurde ein Codierungsansatz verwendet. Dafür wur-

den fünf übergeordnete thematische Kategorien definiert: (1) Digitale Plattformen, (2)

Resilienz, (3) Agilität, (4) Spannungsfeld Agilität/Resilienz und (5) Post-Agilität. Basie-

rend auf den Erkenntnissen und dem Ziel der Forschungsfrage, Resilienz und Agilität im

Rahmen einer Post-Agilen Betrachtung für digitale Plattformen anzuwenden, wurde eine

sechste Kategorie ergänzt: (6) Umsetzung resilienter Post-Agilität in digitalen Plattfor-

men. Diese sechs Kategorien dienten als analytische Säulen und wurden im abschließen-

den Schritt der Datenanalyse und Ergebnisse ausgearbeitet. Die strukturierte Kategori-

sierung ermöglichte eine differenzierte Synthese der Daten. Die Verteilung der Literatur

und den angesprochenen Kategorien ist dabei wie folgt: (1) 11 Studien, (2) 25 Studien, (3)

30 Studien, (4) 18 Studien, (5) 7 Studien und (6) 19 Studien. Die detaillierte Verteilung

der Literatur auf die Kategorien wird in Anhang 1 dargestellt.

4 Ergebnisse

4.1 Literaturverständnis der einzelnen Konzepte

Digitale Plattformen werden innerhalb der SLR als ein facettenreiches und dynamisches

Zwischen Agilität und Stabilität 49

Konzept dargestellt, das weit über eine rein technologische Infrastruktur hinausgeht. Zent-

rale Gemeinsamkeit der Definitionen entlang der SLR ist der Fokus auf Plattformen als

sozio-technische Systeme, die als Vermittlungs- und Interaktionsräume fungieren und den

Austausch von Ressourcen, Informationen und Dienstleistungen ermöglichen [LLL23;

Fa23]. Dieser mehrseitige Austausch wird auch als ein digitales Plattform-Ökosystem auf-

gefasst [He25; OBE24]. Die sogenannten „Multi-Sided Platforms“ [He25; Pr24] haben

sich dabei als dominanter Plattformtyp etabliert: Sie verbinden mehrere Akteursgruppen

und ermöglichen durch Matchmaking-Mechanismen und datenbasierte Architekturen eine

effiziente Wertschöpfung [He25]. Auffällig ist, dass mehrere Autoren entlang der SLR

einerseits die Anpassungs- und Innovationskraft von Plattformen betonen, beispielsweise

durch Echtzeit-Datenanalyse und Transaktionen, KI-basierte Prognosen oder offene API-

und Wissensmanagement-Strukturen [OBE24; Ra18; Yu22; He25]. Sie ermöglichen zu-

dem flexible Kooperation, Wissensaustausch und dezentrale Entscheidungsfindung

[LLL23; Wa22]. Gleichzeitig wird aber auch auf ambivalente Effekte verwiesen, wie etwa

auf die Gefahr marktbeherrschender Strukturen und auf den hohen kompetitiven Druck im

Markt [Pr24; Yu22]. Ein Aspekt der häufig in der SLR betont wird, sind die digitalen

Plattformfähigkeiten („digital platform capabilities“), welche benötigt werden, um mit

Konnektivität und kollektiver Marktgestaltung erfolgreich zu sein [LLL23; ØBO24;

Wa22; Ra18]. Eine gute Ökosystem-Governance einer Plattform umfasst gemäß [Fa23]

dabei vor allem Transparenz, Rechenschaftspflicht und Risikomanagement.

Bezüglich des SLR-Verständnisses von Resilienz, zeigt sich, dass das Konzept als strate-

gisches und dynamisches Konstrukt wahrgenommen wird, das auf verschiedenen Ebenen

(individuell, operativ und strukturell) wirksam wird [Gr25; ØBO24]. Resilienz besteht so-

wohl aus Ressourcen wie Führung, Mitarbeitenden, finanziellen Mitteln und technologi-

scher Infrastruktur [LLL23; Ul24], als auch aus strukturellen Mechanismen wie Ver-

trauen, Kollaboration, Lern- und Entscheidungsfähigkeit [KS25; BA23]. Übergreifender

Konsens der SLR ist, dass Resilienz nicht als Fähigkeit zum Durchhalten konzipiert ist

[Ul24; Wi20], sondern eine aktive Kompetenz ist, um auf Unsicherheit zu reagieren, ro-

bust Stand zu halten und gestärkt aus Störungen hervorzugehen [Gr25; Gö20; RC20; Iy25;

BA23; BNG20; LLL23; Sa24; Yu22]. Es lässt sich festhalten, dass Resilienz zunehmend

als langfristige und integrierte Managementkompetenz verstanden wird, die sowohl prä-

ventive Strukturen (Readiness) als auch reaktive (Response) und transformative

(Recovery) Elemente umfasst [RC20; BSM25; He25]. Mögliche Ansätze zur Resilienz-

förderung sind Risikomanagement, Ökosystemkollaboration, (digitale) Innovation, flexib-

les Leadership und effektive Ressourcennutzung [MM21; RC20; LLL23; Pr24; Sa24;

Iy25; Yu22; Ul24]. [FR17] und [LLL23] verweisen zudem auf den Bedarf innerer Stabi-

lität von Projektorganisation, um Resilienz zu etablieren. Es benötigt zudem einen Fokus

auf die kognitiven Verhaltensstrategien von Organisationsakteuren [ZLZ25].

Abschließend wurde in der SLR das Konzept der Agilität betrachtet. Agilität wird dabei

aufgefasst als ein ursprünglicher produktions- und softwarebezogener Steuerungsansatz

[Iy25; Wi20; Sa24], der sich zu einem Leitbild des organisationalen Handelns entwickelt

hat, welches auf Flexibilität, Reaktionsschnelligkeit und kontinuierliches Lernen zielt

[Ra18; BSM25; Iy25; BA23]. Ein zentrales Muster über die SLR hinweg ist die Deutung

von Agilität als dynamische Fähigkeit, mit der Organisationen sich an Marktveränderun-

gen anpassen [KS25; OBE24; Gö20; Gr25; He25] – ohne einen „vorgefertigten Plan“

[Wi20]. Es wird insbesondere in VUCA-Kontexten die strategische Relevanz betont

50 Larissa Koch de Souza und Martin Engstler

[Bo20; QMN23; HS22]. Zudem ist ein Konsens in aktueller Literatur erkennbar, dass Agi-

lität zwar durch Frameworks und feste Methoden unterstützend eingeführt oder manifes-

tiert werden kann [Sa24; BSM25], es letztlich aber tiefgreifende kulturelle und strukturelle

Veränderungen benötigt, etwa in Form dezentraler Entscheidungsstrukturen, iterativer

Prozesse und technologieoffener Systeme benötigt [Iy25; BNG20]. Dennoch wurde mehr-

fach das Scrum-Framework als populärste Herangehensweise zur Umsetzung von Agilität

aufgeführt [Ci25; Wa22; Bo20]. Auffällig ist, dass entlang der SLR-Literatur unterschied-

liche Fokusse bezüglich Agilität gesetzt werden. [Iy25] und [Sa24] betonen vor allem die

Rolle des agilen Leaderhips, wohingegen [KS25] und [Ul24] die Rolle der Lieferketten-

agilität betrachten und [OBE24] sowie [HNP21] richten sich auf die Kundenagilität aus.

Uneinigkeit herrscht zudem in der Frage, wie stark Agilität formalisiert werden darf, ohne

die adaptiven Potenziale zu behindern [Bo20; Ra18]. [RC20] eröffnen zudem die Frage,

in welchen Kontexten Agilität tatsächlich ökonomisch wirksam und nachhaltig ist.

4.2 Spannungsfeld Resilienz / Agilität

Die Autoren der analysierten Paper zeigen auf der einen Seite ein Verständnis von Agilität

und Resilienz als zwei unterschiedliche, aber unabhängige und koexistierende Fähig-

keiten. Während Resilienz primär mit der Fähigkeit einer Organisation verknüpft wird,

Störungen standzuhalten und auf Stabilität und Langlebigkeit ausgerichtet ist [Gö20;

BSM25], beschreibt Agilität die Fähigkeit, sich dynamisch, flexibel und schnell und auch

effizient an Veränderungen anzupassen, was insbesondere auf kurzfristige Effektivität

zielt [Gö20; He25]. Diese funktionale Trennung beider Konzepte ermöglicht eine vonei-

nander-unabhängige Existenz, da sie verschiedene unternehmerische Herausforderungen

und Zeitdimensionen adressieren [Gö20; KS25; Gr25; Un20]. Der Großteil der SLR-Au-

toren eröffnet jedoch darüber hinaus die Perspektive, dass Agilität und Resilienz nicht nur

koexistieren, sondern in einem dynamischen Zusammenspiel wechselseitig voneinander

profitieren und sich verstärken. Agilität kann nicht nur einen Beitrag zur Krisenbewäl-

tigung leisten, sondern ist ein struktureller Treiber organisationaler Resilienz [BA23;

BSM25; FR17; Sa24]. Beispielsweise sollen agile Strukturen helfen, Veränderungssignale

früher zu erkennen, rascher zu reagieren und dass Organisationen sich schneller erholen

[Un20; Fa23; HS22]. Im Sinne eines „resilient agility“-Ansatzes [Gö20] entsteht aus der

Kombination beider Fähigkeiten so eine übergeordnete Stärke, die nicht nur die Wider-

standsfähigkeit verbessert, sondern gleichzeitig die Wettbewerbsfähigkeit und Flexibilität

erhöht [Gr25; Iy25; BA23; MM21]. In konkreten Anwendungsfeldern wie der digitalen

Transformation [ZLZ25; Ul24], der Lieferkettensteuerung [KS25] oder dem Nachhaltig-

keitsmanagement [Gr25; Iy25; Li25] wurde diese Synergie besonders hervorgehoben.

Agilität fungiert folglich gemäß der untersuchten Literatur überwiegend als ein operatives

Fundament, auf dem Resilienz entstehen kann – und umgekehrt stabilisiert Resilienz agile

Transformationen langfristig. Gleichzeitig betonen aber einzelne Quellen, wenngleich

deutlich weniger, explizit die konfliktären Spannungen und Widersprüche zwischen

Agilität und Resilienz, insbesondere bei einer zeitgleichen Aktivierung beider Fähigkei-

ten. Die Ursache liegt dabei vor allem in den eben dargestellten Grundannahmen und den

zeitlichen Orientierungslinien: Während Agilität häufig kurzfristig ausgerichtet ist zur

schnellen Reaktion und Anpassung, basiert Resilienz auf langfristiger Erholungs- und

Durchhaltefähigkeit [BSM25; Gö20]. Diese Unterschiede können zu Zielkonflikten füh-

Zwischen Agilität und Stabilität 51

ren, beispielsweise wenn unter Krisenbedingungen einerseits flexibel auf Kundenerwar-

tungen reagiert werden soll (agil), gleichzeitig jedoch Ressourcenbündelung stattfinden

muss, um langfristige Stabilität sicherzustellen (resilient) [Gö20]. Diese für Agilität erfor-

derliche minimale Ressourcenbindung und flexible Struktur wird innerhalb der SLR be-

sonders hervorgehoben als Konfliktpotenzial zur Resilienz [Ul24]. [Gö20] und [MM21]

beschreiben Agilität und Resilienz darüber hinaus gleich in mehreren Grundausrichtungen

als entgegengesetzt: reaktiv vs. proaktiv, außen- vs. innenorientiert und wertschöpfend vs.

wertkonservierend. [Bo20] argumentiert implizit gegen übermäßige Agilität, wenn sie zu

Ablenkung und Prozessunterbrechung führt und damit Resilienz behindert. Mehrere Au-

toren der SLR heben jedoch auch hervor, dass Agilität und Resilienz durch einen gezielten

Kompromissansatz gemeinsam vereinbar sein können. Die operative Agilität ermöglicht

kurzfristige Anpassung, muss jedoch durch strategische Vision ergänzt werden, um lang-

fristige Resilienz zu gewährleisten [BSM25; OBE24]. Ebenfalls darf die angestrebte Re-

aktionsschnelligkeit nicht auf Kosten von Robustheit gehen und Stabilität nicht zur Erstar-

rung führen [BSM25; Gö20]. Die Fähigkeit, situativ zwischen agilen (veränderungsnut-

zenden) und resilienten (veränderungsbewältigenden) Mechanismen zu wechseln, gilt als

Kernpunkt der Verzahnung beider Konzepte [Gö20; QMN23; Ho20]. Durch differenzierte

Ressourcenzuweisung, Kontextsensitivität und organisatorische Trennung von kurzfristi-

gen Reaktionsprozessen kann dies umgesetzt werden [Gr25; Gö20; Fa23]. Agilität könnte

somit trotz einzelner Widersprüche eine anpassungsfähige Resilienz fördern und Resilienz

sorgt dafür, dass agile Strategien dauerhaft tragfähig bleiben [Iy25; KS25; Ul24].

Insgesamt stuften somit entlang der SLR verschiedene Autoren das Spannungsverhältnis

zwischen Resilienz und Agilität unterschiedlich ein. Während die meisten Autoren das

verstärkende Verhältnis beider Konzepte sahen, sprachen sich auch einige für eine Ver-

einbarkeit beider Konzepte aus – sei es aufgrund neutraler Unabhängigkeit oder mittels

einer geregelten Kompromissfindung. Der kleinste Teil der SLR-Autoren sprach einen

klaren Widerspruch beider Konzepte an. Die abschließende Verteilung der Einstufungen

durch die entsprechenden Autoren ist in Abbildung 2 ersichtlich.

Abb. 2: Verteilung der Einstufungen des Spannungsverhältnisses von Resilienz & Agilität

4.3 Post-Agilität

Als wichtige Perspektive in der Diskussion von Agilität nannten einzelne Autoren der SLR

52 Larissa Koch de Souza und Martin Engstler

die aktuelle Wahrnehmung und Weiterentwicklung von Agilität. Trotz der ursprünglichen

Rolle von Agilität als Gegenentwurf zu starren Managementmodellen und der zunehmen-

den Bekanntheit des Ansatzes [KS25] bleiben systemische Integration und Projekterfolge

oft aus [Or19; OBE24]. Agilität wird als Fähigkeit zur Bewältigung von Unsicherheit an-

erkannt [OBE24; Fa23], reicht allein aber oft nicht aus, um Disruptionen zu begegnen und

Resilienz anzusprechen [ØBO24]. Insgesamt wird schnell deutlich, dass die aktuelle Be-

wertung agiler Praktiken in der Literatur stark variiert. Während einige sie weiterhin als

strategisches Zukunftskonzept sehen [Fa23; OBE24], kritisieren andere sie als unreflek-

tierte Ideologie [Or19]. Es entstehen Zweifel an der Wirksamkeit in komplexen VUCA-

Umfeldern [Or19; KS25; Un20; Gö20] – insbesondere bei dem aktuell steigenden Streben

nach Stabilität und Orientierung [Ho20]. Als Antwort wird die Idee post-agiler Ansätze

innerhalb der SLR aufgeworfen [Or19]. Post-Agilität soll dabei die Agilität nicht ersetzen,

sondern ehrlich reflektieren, weiterdenken und ergänzen um Themen wie Sinnorientie-

rung, Resilienz, Nachhaltigkeit und Ganzheitlichkeit [Ho20]. Konzepte wie die zuvor er-

läuterte resilient-agile Herangehensweise betonen eine aktive Entfaltung unter Stress

[KS25; Or19; RC20; ØBO24]. Wiederkehrend ist auch der Ruf nach kulturellem Wandel,

inneren Kompetenzen und kollektivem Denken [HS22; BB20; Li25; Ho20; Sa24]. [Ho20]

sowie [Bo20] betonen im Rahmen dessen zudem das Thema der Führung als gemein-

schaftlichen, strategischen Prozess jenseits traditioneller Leitbilder. Zukunftsfähigkeit im

Sinne der Post-Agilität entsteht demnach nicht durch ein festes Verständnis eines agilen

Frameworks, sondern durch reflektierte Verknüpfung von Agilität mit Resilienz, Struktur

und Verantwortung – wird bislang jedoch nur von einem Bruchteil der Literatur gefordert.

4.4 Umsetzung

Digitale Plattformen, die resilient-agile Post-Agilität ermöglichen sollen, müssen viel-

fältige, teils widersprüchliche Anforderungen erfüllen. Die SLR zeigt Konsens darüber,

dass Plattformen sowohl stabile Architekturen als auch agile, anpassungsfähige Ebenen

benötigen, um operative Flexibilität und Systemresilienz zu gewährleisten [BNG20;

Or19]. Dabei darf auch die soziale Perspektive und Kollaborationsförderung nicht verges-

sen werden [BNG20; Ci25]. Offenheit und flexible API-Integrationen fördern Anpas-

sungsfähigkeit an neue Partner, Kunden und Märkte [OBE24; HNP21], während digitale

Infrastrukturen Echtzeitdatenverarbeitung und kontinuierliche Verbesserung ermöglichen

[Ci25; He25; KS25]. Technische Ressourcen allein genügen jedoch nicht – strategische

Lernprozesse und institutionelle Anpassungsfähigkeit sind erforderlich [LLL23; KS25].

Schlüssel zur Resilienz sind zudem eine effiziente Zusammenarbeit, Wissensgenerierung

und eine offene, proaktive Unternehmenskultur [ØBO24; HS22; Sa24; QMN23]. Plattfor-

men benötigen dazu Funktionen wie Projektmanagementunterstützung, Code-Manage-

ment, Prototypen-Tests, Echtzeitkommunikation und Änderungsverfolgung [Ci25;

RC20]. Eine solide technische Basis ermöglicht so Entscheidungs-, Partner- und Kun-

denagilität [OBE24], die jedoch durch eine strategische Lernfähigkeit und klare Zieldefi-

nitionen und Aktionsplänen wirksam werden kann [Ra18; Yu22; BA23].

Innovation gilt grundsätzlich als zentraler Enabler entlang der SLR [KS25; ZLZ25]. Un-

ternehmen in innovativen Umfeldern reagieren robuster auf Störungen, wobei sowohl ra-

dikale als auch inkrementelle Innovation neue Geschäftsmodelle und Fähigkeiten fördern

[Pr24; Ra18]. Kollaborative Netzwerkstrategien und verteilte IT-Systeme erhöhen die be-

Zwischen Agilität und Stabilität 53

nötigte Transparenz und Anpassungsfähigkeit [RC20; Ci25; Gö20; He25; LLL23], wäh-

rend strategische IT-Investitionen und neue Technologien eine proaktive Risikominimie-

rung in Lieferketten ermöglichen [Ul24; He25; Ra18; KS25; Li25; LLL23; Sa24; Yu22;

ZLZ25; HS22]. Unternehmenskulturen mit bereichsübergreifender Zusammenarbeit und

langfristigem Vertrauensaufbau werden von mehreren Autoren gefordert [Sa24; KS25;

Ul24; Yu22]. Entlang dieser Zusammenarbeit benötigt es Wissensmanagement, organisa-

tionales Lernen und intelligente Vernetzung von Wissen und Akteuren [Pr24; Fa23;

QMN23; HS22; Gr25; HNP21]. [LLL23] und [Yu22] heben dabei auch nochmals gezielt

das Teilen von Informationen hervor. Insgesamt zeichnen sich also diese Enabler ab: In-

novation, digitaler Struktur und Technologiennutzung sowie Wissensmanagement und

Kollaboration. Die Umsetzung resilient-agiler Postagilität bei digitalen Plattformen kann

darüber hinaus aber auch durch Tools und Metriken unterstützt werden. Die „Agility

Scale“ [SZ99] beispielsweise erfasst Reaktionsfähigkeit, Flexibilität und Geschwindig-

keit, die „Resilience Scale“ [WFC13] wiederum misst Robustheit und Anpassung [BA23].

[BNG20] bleiben unspezifischer und stellen dafür die Anforderung, dass Metriken wie

Zeit, Kosten, Qualität und Umfang um die Dimensionen der Effizienz und Anpassungsfä-

higkeit ergänzt werden. Das Controlling sollte an diesen Kennzahlen ausgerichtet werden

[FR17]. Ökonomische Kennzahlen wie Umsatzwachstum und Gewinn je Aktie dienen vor

allem als Resilienzindikatoren [ZLZ25]. Innovationszentren, cross-funktionale Teams und

digitale Technologien wiederum können als Tools zur Förderung beider Ansätze aufge-

setzt werden [Iy25; KS25; LLL23; QMN23]. Für Umsetzungen von resilient-agiler Pla-

nung benötigt es jedoch Übersichten und kurzzyklische Bereitstellung von Daten [Wa22].

Die SLR-Ergebnisse zeigen abschließend auch mehrere Barrieren der Umsetzung in der

unternehmerischen Praxis. Beispielsweise erfordert Resilienz kontinuierliche Anpassung

über alle Ebenen, wird aber oft durch (menschliche) Widerstände, mangelnde Führung

und kulturelle Starrheit blockiert [Iy25]. Institutionelles Misstrauen, feste Hierarchien und

instabile Rahmenbedingungen behindern zudem effiziente Ressourcennutzung und kolla-

borativen Wandel [Gö20; Gr25]. Dabei betont [Bo20], dass insbesondere große Industrie-

unternehmen, Dienstleister und Behörden das hohe Maß an benötigter kommunikativer

Koordination kaum aufbringen können. Technologisch gesehen mindern IT-Fokusveren-

gung, IT-Unsicherheit, Governance-Defizite sowie Informationsverzerrungen die Umset-

zung von Agilität und Resilienz [LLL23]. Zudem erschweren veraltete Systeme und hohe

Kosten eine digitale Transformation [Ra18; Wa22; ZLZ25], was besonders relevant ist für

den vorliegenden Kontext der digitalen Plattformendynamiken. [QMN23] und [Sa24] be-

tonen zudem, dass das organisatorische Silodenken und mangelnder Wissensaustausch

Resilienz und Agilität stark behindern. Aber auch fehlende, eigenfokussierte Datenorien-

tierung untergräbt resilient-agile Transformationsprozesse [Fa23; Sa24]. Das organisatio-

nale Lernen als übergreifende Kompetenz eines Unternehmens wird zum Erfolgsfaktor.

5 Diskussion

Die Ergebnisse der SLR geben ein differenziertes Bild über die zentralen Konzepte der

digitalen Plattformen, Resilienz, Agilität, Post-Agilität sowie deren komplexes Zusam-

menspiel. In den einzelnen Definitionen zeigt sich, dass digitale Plattformen zwar häufig

aus technologischer und ökosystemischer Perspektive beschrieben werden, ihre Rolle in

54 Larissa Koch de Souza und Martin Engstler

Bezug auf Resilienz und Agilität jedoch bislang nur vereinzelt betrachtet wird. Das Resi-

lienzverständnis ist hingegen deutlich weiterentwickelt und weist einen breiten Konsens

in der SLR auf. Resilienz wird so überwiegend als dynamische Fähigkeit zur Bewältigung

von Unsicherheiten und Störungen verstanden. Agilität wurde letztlich von den meisten

Autoren (30 von 33) im Vergleich zu den anderen Schlüsselbegriffen thematisiert. Dabei

fällt jedoch aufgrund dessen ebenfalls auf, dass es stark unterschiedliche Einschätzungen

zur aktuellen Relevanz und Entwicklung agiler Methoden gibt. Während einige Autoren

klassische Frameworks wie Scrum und darin verankerter Organisationsregeln weiterhin

als zentral erachten, fordern andere strukturelle Weiterentwicklung in Richtung Dualität,

Kollaboration und Stabilität. Nur ein kleiner Teil der Literatur adressiert jedoch explizit

die Post-Agilität – ein bereits bei der Literatursuche erkennbares Muster. Der Bedarf zur

Weiterentwicklung von Agilität wird erkannt, der ursprüngliche Ansatz wird aber nicht

abgewiesen. Bezüglich der Ausgangsfrage zum Spannungsverhältnis zwischen Resilienz

und Agilität zeigen sich teils komplementäre, teils gegensätzliche Darstellungen – eine

deutliche Heterogenität mit doch starker Tendenz hin zur Vereinbarkeit beider Ansätze.

Insgesamt lässt sich auf Basis der gestreuten Verteilung der Spannungseinstufungen je-

doch ableiten, dass eine strukturierte Balance beider Fähigkeiten notwendig ist.

Unzureichend beantwortet bleibt jedoch die konkrete Operationalisierung der Idee einer

resilient-agilen Post-Agilität im digitalen Plattformkontext. Abschnitt 4.4 versucht dies

aufzugreifen, bleibt jedoch auf Basis der vorliegenden SLR vorwiegend theoriebezogen.

Eine vertiefte Analyse praktischer Umsetzungsformen erscheint daher als zentrales For-

schungspotenzial. Auch weitere Schnittbereiche wie Nachhaltigkeit wurden in der Litera-

tur nur vereinzelt adressiert, obwohl erste Hinweise auf eine Verbindung zu Resilienz und

Zukunftsfähigkeit vorliegen. Dies bildet ebenfalls Potential für zukünftige Forschungen.

Abschließend ist die methodische Herangehensweise der SLR für den Kontext kritisch zu

reflektieren. Die einschränkenden, expliziten Auswahlkriterien könnten relevante Bei-

träge und Aspekte ausgeschlossen haben, insbesondere zur Post-Agilität, die oft nur im-

plizit oder symptomatisch behandelt werden. Generalisierungen der Ergebnisse sollten da-

her mit Vorsicht und dennoch aufmerksam betrachtet werden. Resilienz und Agilität sind

im Plattformkontext eng verknüpft und müssen strategisch gemeinsam gedacht werden.

6 Fazit

Zusammenfassend lässt sich festhalten, dass Resilienzförderung und agile Prinzipien in

einem komplexen Wechselverhältnis stehen, das sowohl verstärkt als auch gestört werden

kann. Agilität wirkt als Katalysator für resilientes Verhalten, wenn sie situativ und reflek-

tiert eingesetzt wird. Resilienz wiederum schafft das strukturelle und langfristig-orien-

tierte Fundament, auf dem agile Prinzipien nachhaltig zur Wirkung kommen können. Es

ist deutlich, dass die Zukunft somit weder in starren Prozessen noch in blinder Flexibilität

liegt. Es benötigt einen bewussten Umgang mit den Synergien, Widersprüchen und den

multiplen Zeitperspektiven beider Ansätze. Ein reflektierender Lernprozess auf mehreren

Ebenen digitaler Plattformen – von der Individual- über die Teamreflexion bis zur struk-

turellen Gesamtsituation – trägt zur Aufarbeitung des Erreichten und der Identifikation

von Weiterentwicklungsmöglichkeiten bei. Offen bleibt jedoch weiterhin, wie dieser An-

satz in Richtung post-agiler Transformation konkret operationalisiert und ausdefiniert

Zwischen Agilität und Stabilität 55

werden kann. Weitere Forschungspotenziale ergeben sich zudem insbesondere im Anwen-

dungskontext der digitalen Plattformen. Es bedarf vertiefender, praxisversierter Studien

zur Frage, in welchen organisatorischen und technologischen Kontexten die Kombination

aus Resilienz und Agilität nicht nur möglich, sondern wirksam wird. Die SLR liefert hier-

für erste Orientierungspunkte, die konkrete Ausgestaltung resilient-agiler Plattformen und

die Ausdefinition des Ansatzes der Post-Agilität bleibt jedoch eine Zukunftsaufgabe.

7 Quellenangaben

[BA23] Bek Yağmur, Ö.; Aydıntuğ Myrvang, N.: The effect of organizational agility on crisis

management process and organizational resilience: Health sector example. International

Journal of Disaster Risk Reduction, 96, 1–13, 2023.

[BB20] Boos, F.; Buzanich-Pöltl, B.: 2 Krisenfest durch Resilienz und Agilität. In (Boos,

F. Hrsg.): Moving Organizations: Wie Sie sich durch agile Transformation krisenfest

aufstellen, Schäffer-Poeschel Verlag für Wirtschaft Steuern Recht GmbH, 2020.

[Be01] Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Fowler, M.; Grenning, J.;

High-smith, J.; Hunt, A.; Jeffries, R.; Kern, J.; Marick, B.; Martin, R.; Mellor, S.; Schwa-

ber, K.; Sutherland, J.; Thomas, D.: Manifesto for Agile Software Development. 2001.

[BH09] Bernardes, E.S.; Hanna, M.D.: A theoretical review of flexibility, agility and respon-

siveness in the operations management literature: Toward a conceptual definition of

customer responsiveness, International Journal of Operations & Production Manage-

ment, 29 (1), S. 30–53, 2009.

[BNG20] Bernus, P.; Noran, O.; Goranson, T.: Toward a Science of Resilience, Supportability 4.0

and Agility. IFAC-PapersOnLine, 53(2), 2020.

[Bo20] Bornewasser, M.: Agile Organisation: Kalter Kaffee oder neue Erfolgsformel? In (Bar-

thel, C. Hrsg.): Managementmoden in der Verwaltung: Sinn und Unsinn, S. 59–91.

Springer Gabler, 2020.

[BPM11] Baskerville, R.; Pries-Heje, J.; Madsen, S.: Post-agility: What follows a decade of agil-

ity? Information and Software Technology, 53(5), S. 543–555, 2011.

[BSM25] Bakry, A.; Sauzeat, N.; Medini, K.: Assessing manufacturing agility: An updated state-

of-the-art and operational insights. In: Procedia CIRP, 132, S. 7–12, 2025.

[Ci25] Ciancarini, P.; Giancarlo, R.; Grimaudo, G.; Missiroli, M.; Xia, T. C.: The Design and

Realization of a Self-Hosted and Open-Source Agile Internal Development Platform.

IEEE Access, PP(99), 1, 2025.

[Fa23] Fasnacht, D.: Offene und digitale Ökosysteme: Mehrwert durch Branchen- und Techno-

logiekonvergenz. Springer Fachmedien Wiesbaden; Imprint: Springer Gabler, 2023.

[FR17] Feichter, A.; Ruthner, R.: Agilität und Resilienz von Unternehmen unterstützen. Con-

trolling & Management Review, 60(S3), S. 38–45, 2017.

[Gö20] Gölgeci, I.; Arslan, A.; Dikova, D.; Gligor, D. M.: Resilient agility in volatile econo-

mies: institutional and organizational antecedents. Journal of Organizational Change

Management, 33(1), S. 1–23, 2020.

56 Larissa Koch de Souza und Martin Engstler

[Gr25] Grebić, B.; Lalic, D. C.; Savkovic, M.; Gracanin, D.; Dakic, D.: From Fragile to Agile:

Building Organisational Resilience through Agile Transformation. In INTERNA-

TIONAL Conference on Business, Management, and Economics Engineering Fu-

ture-BME, 2025.

[He25] Heikinheimo, M.; Hautamäki, P.; Julkunen, S.; Koponen, J.: Dynamic capabilities and

multi-sided platforms: Fostering organizational agility, flexibility, and resilience in B2B

service ecosystems. Industrial Marketing Management, 125, S. 179–194, 2025.

[HNP21] Huang, P.-Y.; Niu, B.; Pan, S. L.: Platform-based customer agility: An integrated frame-

work of information management structure, capability, and culture. International Jour-

nal of Information Management, 59, S. 1–15, 2021.

[Ho20] Hofert, S.: Führen in die postagile Zukunft. In (Hofert, S. Hrsg.): Führen in die postagile

Zukunft: Die Arbeitswelt sinnvoll gestalten und mutig vorangehen. Springer Gab-

ler, 2020.

[HS22] Hunziker, A.; Steiner, C.: Mit agilem Mindset zur Resilienz. In (Schellinger, J.; To-

karski, K. O.; Kissling-Näf, I. Hrsg.): Resilienz durch Organisationsentwicklung: For-

schung und Praxis, S. 139–173. Springer Gabler, 2022.

[Iy25] Iyer, S. S.: Agile Leadership and Strategic Resilience in the Era of Disruptive Innova-

tion: Preparing Organizations for the Future of Work. RA Journal of Applied Research,

11(4), S. 335–344, 2025.

[Ki07] Kitchenham, B.: Guidelines for performing Systematic Literature Reviews in software

engineering. EBSE Technical Report, 2007.

[Kn17] Knight, J.: Go with the Flow: Accelerated digital design in the age of Post-agility. The

Design Journal, 20(sup1), S. 2700–S2715, 2017.

[KS25] Kumar, S.; Singh, V.: Strategic navigation of supply chain ambidexterity for resilience

and agility in the digital era: A review. International Journal of Production Econom-

ics, 281, S. 1–18, 2025.

[Li25] Lilechi, M. C.: Integrating Resilience, Agility, and Sustainability into Future Validated

Supply Chains. Journal of Global Economy Business and Finance, 7(1), S. 47–48, 2025.

[LKM15] Leppanen, M.; Kilamo, T.; Mikkonen, T.: Towards Post-Agile Development Practices

through Productized Development Infrastructure. In 2015 IEEE/ACM 2nd International

Workshop on Rapid Continuous Software Engineering (RCoSE 2015): Florence, Italy,

23 May 2015, S. 34–40. IEEE, 2015.

[LLL23] Liu, R.; Long, J.; Liu, L.: Seeking the resilience of service firms: a strategic learning

process based on digital platform capability. Journal of Services Marketing, 37(3), S.

371–391, 2023.

[LN21] Lindskog, C.; Netz, J.: Balancing between stability and change in Agile teams. Interna-

tional Journal of Managing Projects in Business, 14(7), S. 1529–1554, 2021.

[MM21] Mamaghani, E. J.; Medini, K.: Resilience, agility and risk management in production

ramp-up. Procedia CIRP, 103, S. 37–41, 2021.

[OBE24] Ofoeda, J.; Boateng, R.; Effah, J.: API integration and organisational agility outcomes

in digital music platforms: A qualitative case study. Heliyon, 10(11), 2024.

Zwischen Agilität und Stabilität 57

[ØBO24] Ødegaard, E. E.; Birkeland, J.; Oen, M.: Resilience in Partnership Research—The Role

of Digital Platforms in the Co-creation of Knowledge in Pandemic Times. In (Fleer, M.;

Fragkiadaki, G.; Ødegaard, E. E.; Rai, P.; Sadownik, A. R. Hrsg.): Perspectives in Cul-

tural-Historical Research: Bd. 13. Cultural-historical Digital Methodology in Early

Childhood Settings: In Times of Change, Innovation and Resilience, S. 251–266.

Springer Nature Switzerland, 2024.

[Or19] O’Reilly, B.: No More Snake Oil: Architecting Agility through Antifragility. Procedia

Computer Science, 151, S. 884–890, 2019.

[Pa21] Page, M. J.; McKenzie, J. E.; Bossuyt, P. M.; Boutron, I.; Hoffmann, T. C.; Mulrow, C.

D.; Shamseer, L.; Tetzlaff, J. M.; Akl, E. A.; Brennan, S. E.; Chou, R.; Glanville, J.;

Grimshaw, J. M.; Hróbjartsson, A.; Lalu, M. M.; Li, T.; Loder, E. W.; Mayo-Wilson,

E.; McDonald, S.; McGuinness, L. A.; Stewart, L. A.; Thomas, J.; Tricco, A. C.; Welch,

V. A.; Whiting, P.; Moher, D.: The PRISMA 2020 statement: an updated guideline for

reporting systematic reviews. BMJ (Clinical research ed.), 372, 2021.

[Pr24] Prijadi, R.; Santoso, A. S.; Balqiah, T. E.; Jung, H.; Desiana, P. M.; Wulandari, P.: En-

hancing resilience in digital multi-sided platform start-ups: An exploration of entrepre-

neurial logic and open innovation strategies. Entrepreneurial Business and Economics

Review, 12(1), S. 35–53, 2024.

[QMN23] Quandte, J.; Mnich, P.; Nowotny, V.: Vier Reifestufen einer resilient-agilen Organisa-

tion: Wirkungsvolle Tools und Ideen zur Transformation. Franz Vahlen, 2023.

[Ra18] Ravichandran, T.: Exploring the relationships between IT competence, innovation ca-

pacity and organizational agility organizational agility. The Journal of Strategic Infor-

mation Systems, 27(1), S. 22–42, 2018.

[RC20] Ramezani, J.; Camarinha-Matos, L. M.: Approaches for resilience and antifragility in

collaborative business ecosystems. Technological Forecasting and Social

Change, 151, 2020.

[Sa24] Saumendra, D.; Moushami, P.; Smruti, R.; Sahoo: Agile Change Management: Adapting

Agile Methodologies for Organizational Resilience. Journal of Humanities and Social

Sciences Research, 6(S), S. 41–52, 2024.

[SZ99] Sharifi, H.; Zhang, D.: A methodology for achieving agility in manufacturing organisa-

tions: an introduction. International Journal of Production Economics, 62(1–2), S. 7–

22, 1999.

[Ul24] Ul Akram, M.; Islam, N.; Chauhan, C.; Zafar Yaqub, M.: Resilience and agility in sus-

tainable supply chains: A relational and dynamic capabilities view. Journal of Business

Research, 183, 2024.

[Un20] Unkrig, E. R.: Agilität, Resilienz, Vitalität als Führungsmandate. In (Un-

krig, E. R. Hrsg.): Mandate der Führung 4.0: Agilität – Resilienz – Vitalität, S. 359–365.

Springer Gabler, 2020.

[Wa22] Wagstyl, D.; Borggräfe, T.; Oberdiek, S.; Wagener, L.; Deuse, J.: Digitale Kollaborati-

onsplattform zur verteilten, agilen Planung im Produktentstehungsprozess: Integration

einer IT-Lösung und Indikatoren zur Akzeptanz im industriellen Mittelstand. In: Zeit-

schrift für wirtschaftlichen Fabrikbetrieb, 117(12), S. 879–883, 2022.

[WFC13] Wicker, P.; Filo, K.; Cuskelly, G.: Organizational resilience of community sport clubs

impacted by natural disasters. Journal of Sport Management, 27(6), S. 510–525, 2013.

[Wi20] Wimmers, J.: Agilität und Resilienz als Doppelstrategie. In (Wimmers, J. Hrsg.): Was

ist wesentlich? – Orientierung in einer komplexen Welt, S. 95–107. Springer, 2020.

58 Larissa Koch de Souza und Martin Engstler

[Yu22] Yuan, R.; Luo, J.; Liu, M. J.; Yu, J.: Understanding organizational resilience in a plat-

form-based sharing business: The role of absorptive capacity. Journal of Business Re-

search, 141, S. 85–99, 2022.

[ZLZ25] Zhang, J.; Li, H.; Zhao, H.: The Impact of Digital Transformation on Organizational

Resilience: The Role of Innovation Capability and Agile Response. Sys-

tems, 13(2), 2025.

8 Anhang

Anhang 1: Zuordnung der SLR-Literatur zu den thematischen Kategorien

Autoren

Dig. Platt-

formen

Resilienz Agilität

Span-

nungfeld

Post-

Agilität

Umset-

zung

[BA23]

[BB20]

[BNG20]

[Bo20]

[BSM25]

[Ci25]

[Fa23]

[FR17]

[Gö20]

[Gr25]

[He25]

[HNP21]

[Ho20]

[HS22]

[Iy25]

[KS25]

[Li25]

[LLL23]

[MM21]

[OBE24]

[ØBO24]

[Or19]

[Pr24]

[QMN23]

[Ra18]

[RC20]

[Sa24]

[Ul24]

[Un20]

[Wa22]

[Wi20]

[Yu22]

[ZLZ25]

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 59

Towards a Hybrid Process for Integrating Systems,

Software, and Games Engineering

Marco Kuhrmann1, Philipp Straub1, Julio C. Guzman2 und Jil Klünder3

Abstract: Developing dependable systems is a non-trivial endeavor and requires the implementation

of rigorous processes. Even though modern development techniques enter critical application

domains, still, applying agile methods in such systems’ development constitutes a challenge. At the

Herman Hollerith Center, we run the Rover Lab that supports research activities in the aerospace

domain and, at the same time, provides students with a modern learning environment. The

development of integrated hardware and software systems alongside with development of digital

twins requires a specific software process. In this paper, we present an initial version of such a hybrid

process and its initial evaluation in two instances of the Rover Lab. The evaluation showed the initial

version of the process suitable.

Keywords: Hybrid Development Method, Dependable Systems, Digital Twins, Education

1 Introduction

Agile software development has changed the way, modern software is developed [Ku22]

and, still, there is ongoing change, e.g., due to the emergence of ML and AI [Li20].

However, not in all fields in which software has become relevant, agile methods can be

employed. In domains like aerospace, automotive, or medical devices, standards and

norms put significant constraints on software and systems development, mostly for safety

regulations. Yet, not all parts of such systems fall under regulation and, therefore, hybrid

development methods [Te19] appear to be a good approach to adjust software processes

accordingly.

Context and Contribution In this paper, we present a hybrid development method in

which we combine key elements of systems, software, and games engineering. In the

Rover Lab, which is operated at the Herman Hollerith Center (HHC), we provide a

research and education environment. Students have the opportunity to put software that

1 Reutlingen University, Herman Hollerith Center, Danziger Str. 2, 71034 Böblingen, Germany,

kuhrmann@acm.org, https://orcid.org/0000-0001-6101-8931;

philipp.straub@reutlingen-university.de, https://orcid.org/0009-0003-3868-5789

2 Independent Researcher, (formerly) Reutlingen University, Alteburgstr. 150, 72762 Reutlingen, Germany,

julio.guzman@ucr.ac.cr, https://orcid.org/0009-0000-7732-6779

3 University of Applied Sciences | FHDW Hannover, Freundallee 15, 30173 Hannover, Germany,

jil.kluender@fhdw.de, https://orcid.org/0000-0001-7674-2930

60 Marco Kuhrmann et al.

Outline The rest of the paper is organized as follows: Section 2 provides an overview of

related work, before Section 3 illustrates the research design, which was used to devise

and evaluate the initial version of the process. The process is presented and evaluated in

Section 4. Section 5 concludes the paper.

2 Related Work

In this paper, we provide a hybrid development method that aims to support students in

running their projects in the Rover Lab. Hence, this paper finds its position in the

considerable body of knowledge on software and systems development in regulated

domains that require adherence to certain standards, e.g., ESA’s ECSS series [EC09], as

well as in the field of hybrid methods that aim to bring together those regulated process

and other, e.g., agile, methods [Te19]. However, in the specific setting, another part needs

to be included that is not a first class citizen when it comes to devising software processes:

Games Engineering. Using games as a teaching tool has become an established approach

[Ko16], notably for undergrads, this approach seems to provide notable advantages

[Bo16]. Games are used as a tool that students use to improve their learning, which is often

referred to as “gamification”, but games are also developed as part of the curriculum.

However, the way how games are actually developed is hard to grasp. There exist several

literature reviews, e.g., [OC14], yet, most of the studies conclude that there is some “sort

of agile method” employed for games’ development. In this paper, we therefore consider

games development, for now, as variation of agile software development, and thus use

agile methods together with a games development platform (Unity4).

3 Research Design

We present the steps of incrementally designing a hybrid development method that aims

to develop integrated HW/SW systems alongside with digital twins. For this, we adopt the

case study instrument according to Wohlin et al. [Wo24], which we aligned with the

analysis, conceptualization, and realization steps as defined in the ArSPI model [KHK25].

3.1 Objective and Research Questions

Our overall objective is to provide students with a rigorous, yet agile process to develop

dependable systems in the Rover Lab. To achieve this goal, the target process needs to

address several aspects: (i) it has to cover the HW and SW development parts, (ii) it needs

to provide means to integrate digital twins in the development and operation cycles, and

(iii) it needs to be aligned with actual “real world” processes. Since the use case is the

Rover Lab, i.e., the development of a small Mars rover, the relevant aerospace standards,

4 Unity Game Engine: https://unity.com, last accessed 2025-06-29

Towards a Hybrid Process for Integrating Systems, Software, and Games Engineering 61

e.g., ESA’s ECSS standards are the reference. Hence, we pose the following research

questions:

RQ1: What does a hybrid development method for the Rover Lab look like? The develop-

ment process needs to fulfill several requirements coming along with the target system’s

characteristics. The combination of rigorous processes for dependable systems and slim

agile methods for game development requires a careful selection and combination of

frameworks and practices. This research question aims to answer the question for a

suitable process.

RQ2: What kind of support do students expect from the Rover Lab’s process? The Rover

Lab is both, an educational tool as well as an experimental testbed for actual research.

Hence, the lab can be considered an innovative yet unstable environment. For this, this

research question aims to analyze (i) whether students reached their learning goals and (ii)

what kind of support do students expect the process to deliver.

3.2 Case Selection

The subject of study is the development process for the Rover Lab. This lab completed

two iterations of two semesters each. That is, we opted for the two classes of 2023 (n=7)

and 2024 (n=9) that completed a full turn each in the lab. Both groups shared the same

base requirements and the same introductory material (Section 4.1).

3.3 Data Collection and Analysis Procedures

Data Collection To collect data, one researcher inspected the process-relevant sources to

extract the initial version of the lab’s development process and aligned this process with

the development and mission operation process of NASA’s Mars rovers [Ch14; KSM15]

as reference model. Furthermore, the identified process steps have been aligned with the

relevant ESA standards, namely the ECSS-E-ST-40C [EC09]. This initial process was

discussed with the researchers involved in the lab’s operation. A consolidated version of

the process was presented to the participating students during a guided survey in which

they were presented the process and executed the survey afterwards. The researchers

stayed in the room in case students required a clarification of the questions. The survey

took approx. 15 minutes and consisted of a mixture of closed and open-ended questions

(Table 1).

From the class of 2023, six students that have completed the lab participated in the study.

Likewise, from the class of 2024, six students participated that reached the “feature freeze”

and had four more weeks to go in the lab. The surveys were conducted on May 14, 2025

and yielded in total n=12 interviews.

Data Analysis Since the collected data included quantitative as well as qualitative

informa-tion, the analysis procedures consisted of a mixture of analysis methods. The

quantitative answers were analyzed using simple descriptive statistics, while the open-

62 Marco Kuhrmann et al.

ended questions were analyzed in a qualitative text analysis. To ensure that the researchers

that actively participated in the Rover Lab do not evaluate themselves, another

independent researcher was called in to assure the quality of the evaluation. In particular,

one of the lab’s researchers prepared the data analysis and handed it over to the

independent researcher.

4 Initial Process

In this section, we set the scene by presenting the context of the process’ development in

Section 4.1, presenting the initial (extracted) process in Section 4.2, and the actual process

analysis—the case study—in Section 4.3.

Fig. 1: Overview of the tasks students have to work on in the Rover Lab

Tab. 1: Overview of the questionnaire used for the data collection for the process and lab evaluation

Question Data

Process Evaluation

The presented process adequately reflects the way of work in the rover lab. 4-item Likert

Please rate the intensity of conducting the various process phases:

(i) Requirements Analysis, (ii) System Design (overall system), (iii) Software

Design (overall system), (iv) Software Development (digital twin), (v)

Software Development (hardware-related), (vi) Integration (software parts),

(vii) Integration (overall system, incl. hardware assembly), (viii) Project

Management, (ix) Quality Assurance, and (x) Documentation of the project

and its contents

Numerical

Please briefly describe if and where did you deviate from the process. Free Text

Please evaluate the following statement: If we had this process right from

the beginning, conducting the project would have been easier.

5-item Likert

What extra support in the process would you have like to have? Free Text

Lab Evaluation

Please rate your gained knowledge in the following topics:

(i) Systems Engineering, (ii) Software Engineering, (iii) Games Engineering,

and (iv) Project Management

Please rate the improvement of your skills in the following topics:

(i) Critical Analysis, (ii) Communication, (iii) Modeling, (iv) Programming,

(v) Software Test, (vi) System Test, and (vii) Project Management

Numerical

5-item Likert

Semester 1

Semester 2

Tasks:

−

Check and implement the Kata

−

Analyze how to make the Kata

“autonomous”

−

Analyze what could happen to the

device, e.g., safe states…

Results:

−

Code for the mission algorithm

−

Code for the device

−

UML models for: device, mission,

movement, etc.

−

Use cases for the software and

the device

Tasks:

−

Translate Step 1 into the Unity

environment

−

Add all parts necessary for

conducting a mission, e.g., maps

−

Synchronize Unity parts with the

designs from Step 1

Results:

−

The software rover working in the

game environment

−

Revised sets of models and code

−

A virtual mission to demonstrate

the working software rover

Tasks:

−

Analyze device’s capabilities

−

Assemble the first device and test

the device, e.g., sensors

−

Translate the software rover into

the hardware rover

−

Connect and test the device with

the digital twin and run in on-site

−

Synchronize findings (Step 1+2)

Results:

−

The “sandbox” device (test bed)

runs the missions controlled by

the digital twin

Tasks:

−

Assemble the second device and

test it like the first device

−

Design a mission in Unity

−

Deploy the mission to the device

−

Conduct the mission

−

Provide mission status and results

Results:

−

Operating rover in the target

environment without safety net

−

Device accepting and conducting

a mission autonomously

−

Device must not destroy itself!

Towards a Hybrid Process for Integrating Systems, Software, and Games Engineering 63

4.1 Setting the Context

The context of the study at hand is the Rover Lab5 that is operated in the HHC of

Reutlingen University. This lab serves two purposes: first, the lab is an education-related

environment in which the students learn modern software development approaches,

namely software and systems engineering in combination with games development. Based

on the mission profile of the two Mars rover twins Spirit and Opportunity, students

replicate this setting by analyzing a mission, which is given by the Mars Rover Kata6 ,

designing the required software to control a rover, assemble a small rover themselves, and

develop a digital twin that serves as Mission Control Center (MCC) for conducting the

actual mission. The Rover Lab is also a research testbed, which was established in a

research project.

Learning Goals The Rover Lab aims to deliver a particular set of skills to the students.

Students shall understand and apply selected topics from Systems Engineering, Software

Engineering, Games Engineering, and Project Management. These skills include critical

analysis, modeling, developing, testing, and communication. The activities are combined

alongside the different topics. That is, analysis and modeling tasks start at the system level

and have to be broken down to the software level. Therefore, students have to design a

system at different levels of abstraction and, accordingly, have to implement, integrate and

test the different components until the full system is operational (hardware and software).

Student Tasks In the lab, the students run through a number of tasks, which are illustrated

in Fig. 1. The lab spans two semesters of which the first one is focused on analyzing the

problem and specifying the solution, and the second semester is focused on the actual

system development. To properly reflect the Mars rover mission context, students also

assembled two rovers per group: one as a “sandbox” test device for the development and

on-site tests, and one as mission device, which conducts a mission autonomously. The

device-assembling task also forms the interface between the two semesters such that the

students, when starting the second semester, have already seen all relevant system

components.

Development Approach The development approach used in the lab is based on Feature-

driven Development (FDD). Specifically, due to the context of the lab, various practices

are integrated to (i) fulfill the requirements raised by the case (see Section 4.2), to (ii)

provide sufficient structure for the students to learn the various tasks, and (iii) respect the

actual target environment, which is developing a “game”. That is, in the lab’s hybrid

method [Te19], different fine-grained methods and practices are integrated, notably: Use

Case Analysis, Object-oriented Design, Pair Programming, and management techniques

such as management via/estimation based on User Stories. Furthermore, several project

5 The lab provides: 4 4tronix M.A.R.S. rovers, 1 Mac Mini M2Pro general server, 1 Mac Studio M2Max AI-

server, a 87-inch mobile touch screen, 1 MinisForum UM790 Venus as deployment target, and an own Wifi

network.

6 Online: Kata-Logs, Mars Rover Kata, https://kata-log.rocks/mars-rover-kata, last accessed 2025-06-28

64 Marco Kuhrmann et al.

activities employ empirical methods, e.g., the analysis of the device that includes various

experiments and tests to quantify the device’s capabilities.

4.2 Extracted Process

In the starting phase of the second Rover Lab instance, we started to formalize the lab’s

process to improve the guidance for the students. One researcher started to study the

original development and operation process of NASA’s Mars rovers, mapped this process

to the ECSS standards and, eventually, assigned the so far known/documented

development steps. A simplified version of the initial model is shown in Fig. 2. The

process consists of six explicit steps of which four are refined in respective, fine-grained

sub-processes.

Due to the setting of the Rover Lab and its semester-overlapping tasks (Fig. 1), an exact

mapping from the reference processes to the actually implemented one in the lab was not

executed in this initial version. However, as an orientation, the first four phases shown in

Fig. 2 roughly match the first semester, and the phases 3–6 roughly match the second

semester. The overlapping two phases comprise activities that connect the two semesters,

e.g., refinement of the requirements to low-level requirements. These mappings have been

presented and explained to the students in the course of the data collection (Section 3.3).

The process shown in Fig. 2 represents the teachers’/researchers’ perspective on the Rover

Lab based on reference models and available project documentation. Hence, the evaluation

as presented in subsequent sections aims to evaluate the accuracy of the process and,

furthermore, the suitability of the process to run the lab.

4.2.1 Step 1: Software Systems Requirements

Figure 3 provides the refinement of the first step of the overall process (Fig. 2). The focus

of this step is the requirements engineering and its activities. For analyzing mission and

system requirements, use cases are used as analysis and documentation technique. Also,

for the fine-grained specification of the device’s behavior, state machines7 are used.

7 State machines are modeled theoretically and practically as executable models using Stately (https://stately.ai).

Concept of

Operations

Requirements and

Architecture

Detailed Desig n

Development and

Fabrication

System Verificatio n

and Validation

Operation Phase

Disposable

Custom Model: HSR Rover Lab

Software System

Requirements

Verification of

Requirements

Software

Requirements

Review

Software Design

and Implementation

Software Operations

Wrap-Up and

Clean ing

Reference Model: NASA Rover Opportunity

Fig. 2: Overview of the initial Rover Lab process including the reference process by NASA and the

ESA standards assigned to the individual development phases

Towards a Hybrid Process for Integrating Systems, Software, and Games Engineering 65

Most of the activities in this step address the system level and are focused on the use cases

that build the foundation for the following refinement steps. Furthermore, due to the hybrid

nature of the system of interest, in this step, initial architecture designs are also produced

to reflect the various system parts.

4.2.2 Step 2: Verification of Requirements

While the first step is primarily concerned with understanding the system and

conceptualize the required features to build it, the second step as shown in Fig. 4 aims at

refining and verifying the requirements and early designs (still at the system level).

Specifically, in this step, the first iteration of the fine-grained requirements is developed.

For this, use cases are refined into specific requirements that are documented using the

PARIS templates [Li22]. This translation process undergoes a stringent peer review.

Alongside the refinement, the actual device is assembled and evaluated. For this, a series

of controlled experiments is conducted to determine the specific capabilities of the device,

e.g., maneuverability or general functionality of the hardware. Based on the resulting

experiment data, the requirements are refined in a second iteration to adequately reflect

the hardware in the requirements. Finally, the specific requirements for the digital twin

are collected and documented.

4.2.3 Step 3: Software Requirements Review

The third step (Fig. 5) is focused on the specific refinement of the component-specific

requirements for the purpose of making the requirements “ready-to-implement”. That is,

requirements are refined into low-level requirements that are, practically, manifested into

development tickets in the GitLab system, i.e., development task. This refinement step

concludes with a first prototype of the digital twin that also forms the primary review

artifact.

Software System

Requirements

Analyze HW

Requirements

Specify HW

Requirements

Analyze Mission

Requirements

Analyze System

Requirements

Analyze SW

Requirements

Specify SW

Requirements

Fig. 3: Refinement of the first process step with a focus on requirements engineering activities

Verification of

Requirements

Assemble Rover

Test and Measure

Rover

1st Refine SW

Requirements

Verify SW

Requirements

2nd Refine SW

Requirements

Specify DT

Requirements

Fig. 4: Refinement of the second process step with a focus on requirements refinement activities

66 Marco Kuhrmann et al.

4.2.4 Step 4: Software Design and Implementation

While the third step (Fig. 5) represents the transition from the system level to the specific

hardware and software levels, the fourth step (Fig. 6) focusses on the distinct components.

In this step, the major development tasks are executed.

For the development of the software components, FDD is employed, which is a “natural”

choice as most of the system’s functionality is designed as functional blocks. For each

feature, it must be defined how the feature manifests in the system. Especially for those

features that are in the digital twin component, a feature might consist of plain code, game

assets and scenery, graphics manipulation, and so forth. Also, for each feature in the digital

twin, it has to be ensured that the twin’s behavior matches exactly the device’s behavior.

4.3 Process Evaluation

In this section, we present the results of the process evaluation (Table 1). Figure 7 shows

that the students agree with the process’ accuracy, i.e., the process extracted from the

project data reflects their way of work. However, students also stated that they deviated

from the process, notably in the class of 2023. In this class, the hardware development8

started at a different point in time than in the second class. A bit more diverse are the

answers to the question for the usefulness of the process and its availability from the

8 Note that HW development was initially not planned at all for this course and it was decided after the lab’s

start to also go for the HW parts. In the second class, HW development was scheduled from the very

beginning on.

Software

Requirements

Review

Review HL-SW

Requirements

Review LL-SW

Requirements

Review DT

Prototype

Review LL-HW

Requirements

Review HW State

Machine

Fig. 5: Refinement of the third process step with a focus on specifying low-level requirements

Software Design

and Implementation

Realize HW

Components

Integrate and Test

All Components

Design Overall

System

Realize SW

Components

FDD-based

Development

Integrate and Test

SW Components

Realize DT

Components

Fig. 6: Refinement of the fourth process step with a focus on the software development activities

Towards a Hybrid Process for Integrating Systems, Software, and Games Engineering 67

beginning on. While the class of 2023 is indifferent, the class of 2024 would have

appreciated this guideline.

Fig. 7: Summary of the perceived accuracy (left) and usefulness (right) of the lab process by class

The second relevant aspect regarding the adequacy of the process is the collection of

activities to be executed within the process. For this, Fig. 8 shows the aggregated intensity

of executing the activities per class and relates these to the variance per activity per person.

Fig. 8: Summary of the intensity of conducting the different lab activities by class including variance

Figure 8 allows for two observations: (i) all activities were executed with a comparable

intensity and (ii) within the teams, specializations regarding the work’s focal points

become obvious. Since the figure suggests that no general differences exist between the

classes, we backed up this impression with a Mann-Whitney U-Test that resulted in an

 = 47,  = 0.189,  = 0.84 with a significance level of 0.05 and thus suggests that there

is no difference in the relative aggregated intensities between the classes.

The question for missing elements yielded three elements: (i) a big picture of the project

as such was mentioned missing, which is in line with result shown in Fig. 7 (right), (ii) an

improved introduction to Unity was mentioned once, and (iii) an improved support for the

requirements documentation using PARIS [Li22] was requested9.

We conclude that the initial process, including all elements adequately reflects the way of

work in the Rover Lab and, therefore, provides an adequate hybrid development method

for operating the lab (RQ1, Section 3.1).

Class 2024 Class 2024 4

Class 2023

0 1 2 3 4 5

Completely agree Largely agree Not answered

0 1 2 3 4 5

Agree Completely agree No difference Not answered

48 54

50 53

47 50

50 53

42 51

47 47

45 49

44 56

47 47

45 52

10 60

7 40

5 30

3 20

2 10

0 0

Requirements System Design Software Design Software Software Integration (Software Integration Project Management Qua lity Assurance Project

analysis (Complete System) (Complete System) Development (Dig ital

Twin)

Development

(Hardware-related)

Components) (Complete System) Documentation

68 Marco Kuhrmann et al.

4.4 Lab Evaluation

The second part of the lab’s evaluation was concerned with the students learning. That is,

does the process cover and structure all topics relevant to support the students’ learning.

For this, based on the questions from Table 1, Fig. 9 shows the perceived knowledge gain

per class and per student. The figure shows that all students but two had a significant

knowledge gain, i.e., learned new things. Yet, Systems and Games Engineering were new

to all but one student. Despite these two extremes, on average, the total gain was

approximately 8.25 ± 0.5.

While Fig. 9 provides a break down to the student level, Fig. 10 draws the big picture and

shows that notably modeling and testing constitute the biggest learning in the studied

groups. Besides the quantitative evaluation, we also asked the students for small

statements in a 5-minute-paper style in which we asked them for up to five positive and

negative aspects, as well as for improvement opportunities. Finally, we asked the students

for their personal main take-away. Among the positive aspects, the team project and the

supervision were the most frequently mentioned aspects. Also, the diversity of subjects

(hardware and software) and the game development were mentioned. On the downside,

the (immature) PARIS tool was the only mentioned negative aspect that also constitutes

the most frequently mentioned improvement requirement, i.e., improve the tool support

and the methodological guideline for PARIS-based requirements documentation.

Finally, the specific challenges of conducting a project in which a software is co-

developed with a technical (embedded) device was considered an important take away.

Also the necessity for a good project structuring and organization approach was stated.

Fig. 9: Summary of the gained knowledge by class (left: 2023, right: 2024) per topic (discipline)

Systems Engineering Software Engineering

Games Engineering Project Management

S1.1

Systems Engineering Software Engineering

Games Engineering Project Management

S2.1

S1.6

S1.2

S2.6

S2.2

S1.5

S1.4

S1.3 S2.5

S2.4

S2.3

Towards a Hybrid Process for Integrating Systems, Software, and Games Engineering 69

Fig. 10: Summary of the skill improvement all participants topic (activities)

We conclude that the Rover Lab provides a good learning environment for the students.

As the lab is grounded in a research project located in one of the most demanding

application domains, the lab inherently exposes the students to many real-world problems

going beyond a “normal” student project, even if the lab is substantially tailored and

simplified to fit the students’ learning progress. To answer RQ2, no process items were

mentioned missing.

5 Conclusion and Future Work

In this paper, we presented an initial version of a hybrid method developed for a research

and learning environment. The hybrid method addresses systems, software, and games

engineering to meet the requirements posed by the HHC’s Rover Lab. The process’

construction followed a process improvement approach, which we complement with a

case study to conduct the process’ evaluation. The evaluation with 12 students in the lab

showed the initial version of the process suitable and no elements were identified missing.

This process lays the foundation for future lab instances. Therefore, future work includes

a continuation of the process modeling to provide more details and guideline elements as

requested by the students, e.g., big pictures. Also, the process will be enriched with a

specific Unity template, which is currently under development, to kick-start the

development of the digital twins.

6 References

[Bo16] Bodnar, C. A. et al.: Engineers at play: Games as teaching tools for undergraduate

engineering students. Journal of engineering education 105 (1), pp. 147–200, 2016.

[Ch14] Chattopadhyay, D. et al.: The Mars Science Laboratory Supratactical Process. In:

SpaceOps Conference. American Institute of Aeronautics and Astronautics, 2014.

[EC09] ECSS Secretariat: Space Engineering - Software, Standard ECSS-E-ST-40C, European

Cooperation for Space Standardization, 2009, https://ecss.nl/standard/ecss-e-st-40c-

software-general-requirements/, accessed: 06/29/2023.

[KHK25] Kuhrmann, M.; Hebig, R.; Klünder, J.: You don’t just Use Software Processes, You have

to Engineer Them: A Teachers’ Experience Report. In (Mottok, J.; Hagel, G., eds.):

10 9

Analyzing Critically Communication Mo deling Programming Software Testing Testing the Complete Project Management

System

No change Small improvement Me dium improvement Good improvement Significant improvement

70 Marco Kuhrmann et al.

Proceedings of the 6th European Conference on Software Engineering Education, ECSEE

2025, Seeon, Germany, June 2-4, 2025. ACM, pp. 210–220, 2025.

[Ko16] Kosa, M. et al.: Software engineering education and games: a systematic literature review.

Journal of Universal Computer Science 22 (12), pp. 1558–1574, 2016.

[KSM15]Kand, M. S. T.; Sadeghian, R.; Masouleh, M. T.: Design, analysis and construction of a

novel flexible rover robot. In: RSI International Conference on Robotics and Mechatronics

(ICROM). IEEE, 2015.

[Ku22] Kuhrmann, M. et al.: What Makes Agile Software Development Agile? IEEE Trans.

Software Eng. 48 (9), pp. 3523–3539, 2022, https://doi.org/10.1109/TSE.2021.3099532.

[Le22] Lehner, D. et al.: Digital Twin Platforms: Requirements, Capabilities, and Future

Prospects.IEEE Softw. 39 (2), pp. 53–61, 2022,

https://doi.org/10.1109/MS.2021.3133795.

[Li20] Liu, H. et al.: Emerging and Changing Tasks in the Development Process for Machine

Learning Systems. In: ICSSP ’20: International Conference on Software and System

Processes, Seoul, Republic of Korea, 26-28 June, 2020. ACM, pp. 125–134, 2020.

[Li22] Linssen, O.: Anforderungen strukturiert mit Schablonen dokumentieren in PARIS. In:

Projektmanagement und Vorgehensmodelle 2022 - Virtuelle Zusammenarbeit und

verlorene Kulturen? - PVM 2022, Trier, Germany, September 8-9, 2022. Vol. P-327. LNI,

Gesellschaft für Informatik e.V., pp. 109–139, 2022.

[OC14] Osborne O’Hagan, A.; Coleman, G.; O’Connor, R. V.: Software development processes

for games: A systematic literature review. In: Systems, Software and Services Process

Improvement: 21st European Conference, EuroSPI 2014, Luxembourg, June 25-27, 2014.

Proceedings 21. Springer, pp. 182–193, 2014.

[Te19] Tell, P. et al.: What are hybrid development methods made of? An evidence-based

characterization. In: Proceedings of the International Conference on Software and System

Processes. ICSSP, IEEE / ACM, pp. 105–114, 2019.

[Wo24] Wohlin, C. et al.: Experimentation in Software Engineering. Springer, 2024.

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 71

Fit for Agility? Exploring Person-Job Fit in SAFe Teams

Ninja Leikert-Boehm 1, Katja Kurz1, Michèle Trebo1 und Philipp Matter1

Abstract: Agile frameworks such as SAFe assume employees naturally align with values of

collaboration, self-organization, and adaptability. However, psychological and developmental

misalignments can undermine agile transformations. This exploratory, mixed-methods study at a

large Swiss organization examined person-job fit across four SAFe-organized teams, combining

data on personality (Big Five), motivation (Self-Determination Theory), and values (Spiral

Dynamics). The findings reveal three types of potential misalignment – structural, cultural, and

developmental – associated with autonomy and competence satisfaction and perceived team

performance. High-performing teams demonstrated stronger alignment across psychological and

value dimensions, while mid-performing teams experienced friction due to autonomy constraints

and cultural dissonance. The study highlights a diagnostic gap in scaled agile practice: current

frameworks often overlook psychological diversity and motivational needs. We propose a holistic

extension to the person-job fit model and outline practical implications of this human-centered

diagnostic approach.

Keywords: Scaled Agile, SAFe, Big Five, Self-Determination Theory, Spiral Dynamics

1 Introduction

The Scaled Agile Framework (SAFe) has emerged as a widely adopted approach for

enabling agility across large organizations [Di23]. Yet, its implementation often

encounters systemic challenges, particularly at the individual and team levels. While its

structured layers and clearly defined roles promise improved coordination and strategic

alignment, empirical observations indicate persistent performance and engagement issues

[Di16], [Ed22].

Agile frameworks implicitly assume that employees naturally align with core agile values

– self-organization, autonomy, adaptability, transparency and collaboration [Hu22],

[Ye23], but empirical research increasingly finds that such assumptions fail in practice

[Ny22], [Ed22]. Individual psychological traits (e.g., openness, conscientiousness),

motivational orientations (e.g., autonomy and relatedness needs), and value systems

shaped by developmental stages (e.g., ego development, Spiral Dynamics) may

significantly influence how employees experience and perform in agile environments.

When individual dispositions and needs misalign with the structural and cultural demands

1 Zurich University of Applied Sciences, School of Management and Law, Theaterstrasse 17, 8401 Winterthur,

ninjairina.leikert-boehm@zhaw.ch, katja.kurz@zhaw.ch, mitr@scip.ch, philipp.matter@zhaw.ch

https://orcid.org/0000-0002-8815-0198

72 Ninja Leikert-Boehm et al.

of agile roles, negative consequences may include decreased team cohesion, reduced

perceived autonomy, and impaired performance [Ne99].

To understand the underlying dynamics, this study investigates two research questions:

• RQ1: How do individual, psychological characteristics – personality traits,

motivational needs, and developmental perspectives – influence perceived person-job

fit (PJF) in SAFe-organized agile teams?

• RQ2: How do structural and cultural characteristics of the SAFe implementation

influence employees’ experience of PJF?

We present an exploratory mixed-methods study at a large Swiss organization with over a

decade of SAFe practice. Drawing on psychological assessments and qualitative

interviews across four agile teams, the study identifies structural, cultural, and

developmental misalignments that shape perceived PJF and team outcomes. This

contribution integrates psychological and developmental theories into agile transformation

research, proposing a human-centered diagnostic approach to identifying and addressing

person-job misalignments – laying the groundwork for targeted interventions that can

sustainably enhance agility at scale.

The paper is organized as follows: Section 2 introduces the background on scaled agility,

person-role fit (PRF) and PJF, and psychological and developmental models. Section 3

outlines the study’s design. Section 4 presents the results across teams. Section 5 discusses

the implications, limitations, and future research, and Section 6 concludes the paper.

2 Background

This chapter outlines the theoretical background, beginning with agile methods and their

scaling, followed by models of PJF and PRF in agile contexts, and concluding with

psychological and developmental perspectives.

2.1 Agile and Scaled Agile frameworks

Agile methods emerged in the early 2000s to counter rigid development models by

promoting adaptability, collaboration, and iterative delivery [Be25]. Frameworks like

SAFe extend these principles to larger organizations, with SAFe being the most widely

adopted [Di23], [Ul22]. It formalizes agility across organizational layers with defined

roles, events, and artifacts aimed at balancing alignment and decentralization [Kn20].

However, its implementation often reintroduces hierarchical control and prescriptive

routines, creating tension between agile values and the operational realities of large-scale

environments [Ed22], [Ho20].

These tensions also extend to the psychological level, where they can undermine

engagement and motivation. Agile frameworks often overlook individual variability in

traits, needs, and developmental readiness, instead promoting uniform role expectations.

This can contribute to person-role misalignments and, in turn, to reduced performance. To

Fit for Agility? Exploring Person-Job Fit in SAFe Teams 73

support sustainable scaled agility, a more holistic approach is needed – one that integrates

organizational design with psychological and developmental insight.

2.2 Person-job fit and person-role fit in Agile contexts

Psychological alignment in scaled agile environments can be analyzed through two

complementary constructs: Person-job fit and person-role fit. As conceptualized by

Edwards [Ed91], PJF refers to the congruence between individual characteristics and the

formal demands and resources of a job. It links fit to outcomes such as satisfaction,

performance, and turnover, based on relatively stable job structures. DeRue and Morgeson

[De07] define PRF as the match between individual capabilities and the dynamic, socially

constructed expectations of a role. Their study shows that PRF evolves through feedback,

self-efficacy, and growth satisfaction – an especially relevant process in agile

environments where roles are fluid and shaped through team interaction [Il91].

Brkich et al. [Br02] developed a self-report instrument to assess PJF. It focuses on role

attributes such as autonomy, influence, and purpose, which are core dimensions of agile

teamwork. Misalignments in these areas can hinder employee’s engagement and

performance.

Scaled frameworks formally define roles to support coordination and consistency across

teams and portfolios [Ed22]. Given the dual nature of roles, being both formally defined

and enacted dynamically, this study applies PJF as its central analytical lens. It provides a

measurable, scalable framework that is suitable for SAFe environments.

2.3 Psychological and developmental perspectives in Agile work environments

Successful SAFe adoption depends not only on processes but also on psychological

alignment with agile principles and values [Di16]. Psychological and developmental

models help explain why some individuals thrive in agile environments, while others

experience friction or disengagement. Agile ways of working place substantial cognitive

and emotional demands on individuals, making it essential to understand how they

respond. To address this variation, we draw on three complementary perspectives:

personality traits, motivational needs, and developmental stages [Ro07], [De00], [Ke98].

Trait-based models include the Myers-Briggs Type Indicator (MBTI), the HEXACO

model, and the Big Five model [My85], [As07], [Jo99]. While MBTI is popular in

practice, the Big Five is dominant in academia due to its empirical reliability [Mc08]. It

describes five personality dimensions that influence collaboration and adaptability:

openness, conscientiousness, extraversion, agreeableness, and neuroticism. In agile

settings, high openness and conscientiousness are beneficial, while high neuroticism may

lead to stress and disengagement [Em22].

A second analytical lens is the Self-Determination Theory (SDT), which highlights three

core psychological needs: autonomy, competence, and relatedness [De00]. Satisfying

these needs is essential for intrinsic motivation, engagement, and well-being. Agile

74 Ninja Leikert-Boehm et al.

frameworks aim to foster such conditions, yet scaled models such as SAFe can limit

autonomy and relatedness through their structured roles and processes [Ed22].

Finally, developmental models offer a longitudinal view on how individuals interpret

complexity, authority, and interdependence. Theories such as Loevinger’s ego

development and its extensions [Lo97], [Co10], [To04] describe psychological maturation

across stages. This study focuses on Spiral Dynamics, which maps evolving value systems

at both individual and collective levels. Misalignments can occur when agile values of

participation and integration conflict with traditional, efficiency-driven norms. Individuals

valuing stability and hierarchy may struggle with agile demands for self-organization and

role fluidity. Spiral Dynamics identifies value patterns through so-called vMemes relevant

for individuals, organizations and society [Gr74], [Be14].

vMeme

Color

Way of

thinking followed by structure and process

BEIGE

automatic

loose bands

survivalistic

PURPLE

animistic

tribal

circular

RED

egocentric

empires

exploitative

BLUE

absolutistic

pyramidal/hierarchical

authoritarian

ORANGE

multiplistic

delegative

strategic

GREEN

relativistic

egalitarian

consensual

YELLOW

systemic

interactive

integrative

TURQUOISE

holistic

global

ecological

Tab. 1: Characteristics of vMemes [Be14]

Two value memes particularly relevant in agile settings are the orange meme, which is

centered on achievement and autonomy, and the green meme, which emphasizes

participation and relational cohesion [Be14]. Increasingly, the yellow meme gains

importance, as it reflects systemic thinking, integration, and comfort with complexity –

traits seen as key for advanced agile practice. While agile methods can be applied from

earlier stages, their sustained success may depend on individuals and teams operating from

later, more evolved value systems [Be14], [La15]. Commercial tools like the ValueMatch

assessment2 translate these value patterns into actionable diagnostics, supporting both

organizational design and leadership development, though results should be interpreted as

indicative rather than psychometric.

3 Research method

This exploratory mixed-methods case study at a large Swiss organization examines

individual fit in agile teams within a SAFe environment, supporting in-depth investigation

of complex phenomena [Ei07], [Yi18].

2 https://www.valuematch.net

Fit for Agility? Exploring Person-Job Fit in SAFe Teams 75

3.1 Case introduction and context

The study was conducted at a large Swiss technology provider that has implemented SAFe

since 2012. By 2019, the organization had adopted a full SAFe 5.0 configuration,

encompassing approximately one-sixth of its workforce – primarily those in software

development. At the time of the study, the company operated under SAFe 6.0 with agile

team structures and lean portfolio management in place. This maturity offers a robust

context to study scaled agility in practice.

The organization exhibits structural layering and performance orientation – traits aligned

with blue (structure, control) and orange (efficiency, competition) value systems in Spiral

Dynamics. Four agile teams were selected to reflect different performance levels, enabling

comparison of PJF under shared structural conditions.

3.2 Data collection and analysis

Data collection combined quantitative surveys and qualitative interviews. Participation

required that each team’s Scrum Master (SM) had provided a subjective team performance

rating, forming the basis for team selection. Quantitative data were collected using a set

of survey instruments (the first three consolidated into a survey with each interviewee):

• The Global PJF Scale [Br02] was used to assess the perceived alignment between

individual characteristics and job-related demands.

• The Big Five Inventory-10 [Ra14] was used to measure personality traits using the

psychometrically validated short-form instrument.

• The Work-related Basic Need Satisfaction Scale [Va10] evaluated the perceived

fulfillment of autonomy, competence, and relatedness according to SDT.

• The ValueMatch (VM) assessment based on Spiral Dynamics was used to identify

individual value and cultural profiles, and to derive consolidated group-level profiles.

Semi-structured interviews with selected team members explored experiences of fit,

motivation, and collaboration. A deductive coding process, guided by the theoretical

framework, was applied and cross-validated between authors.

Table 2 provides an overview of the teams, their subjective performance rating according

to the respective SM, and the extent of data collection across interviews and surveys. Data

availability varied by team, reflecting differences in participation, available data points,

and the roles of interviewed participants. Data collection took place between January and

April 2024. While Teams H1, M1, and M2 contributed psychological, motivational, and

value-based data through interviews and surveys, Team H2 provided only a VM group

profile. The roles represented span key SAFe team functions such as SM, Product Owner

(PO), Technical Lead (TL), and Developer (Dev or DevOps).

76 Ninja Leikert-Boehm et al.

Team

Subjective

Perfor-

mance

Participants / Team Size

Roles of Interviewees

Interviews &

Survey VM Profile

High

4 / 4

SM, PO, 2x Dev

High

0 / 7

7 / 7

Medium

5 / 9

9 / 9

SM, TL, 3x DevOps

Medium

2 / 10

7 / 10

PO, Dev

Tab. 2: Data collection overview

Integrating survey and interview data enabled triangulation, strengthening the validity of

the insights. By linking psychological, motivational, and value-based profiles with

participants’ narrative accounts, the study revealed initial patterns of misalignment in

scaled agile environments.

4 Results

This section presents comparative findings from four agile teams to explore PJF through

psychological, motivational, and cultural perspectives. It then synthesizes indicative fit

and misalignment patterns that distinguish high- from mid-performing teams within

shared SAFe conditions.

4.1 Comparative patterns of person-job fit across teams

Team H1 was rated as high-performing by its SM. All four team members participated in

the study and reported high PJF scores. Personality traits showed uniformly high

conscientiousness, agreeableness, and openness, with low neuroticism. Autonomy and

competence satisfaction were consistently high, reflecting a psychologically and

motivationally coherent climate.

The team’s VM profile revealed a dominant orange-green orientation with moderate

acceptance of blue, which supports SAFe structures while enabling participative

adaptation. Interviews described the team as self-steering with a critical look at overhead

tasks but generally feeling empowered to adapt team processes and ceremonies

autonomously. This convergence suggests strong fit between individual dispositions, team

dynamics, and agile role expectations.

Team H2, also rated as high-performing by its SM, contributed only the VM group profile.

It indicated a coherent orange-green orientation and moderate blue acceptance with

aspirations for more yellow values according to Spiral Dynamics. This suggests cultural

fit with the SAFe organization. Even without additional psychological data, the profile

offers preliminary indications consistent with patterns observed in high-performing teams.

Team M1, classified as mid-performing by its SM, participated with five out of nine team

members in all surveys and interviews. PJF scores varied, reflecting divergent

Fit for Agility? Exploring Person-Job Fit in SAFe Teams 77

experiences. Personality data showed high conscientiousness but more variability in

openness and partially elevated neuroticism. Although the needs for competence were

generally met, satisfaction with autonomy ranged widely. Those with the lowest PJF

ratings felt micromanaged.

The team’s VM profile reflected an orange-green orientation with low blue tolerance,

leading to tension with SAFe structures. Interviewees described rigid ceremonies and

inconsistent psychological safety. These patterns suggest a psychological and cultural

misalignment, where individual traits and motivational needs only partially align with

structural conditions.

Team M2, categorized as mid-performing team by its SM, contributed data from only two

out of ten members. PJF scores were moderate, with one notably lower. Both individuals

showed high conscientiousness, moderate openness and agreeableness, and in one case,

elevated neuroticism. Autonomy and competence needs were partially met; relatedness

was low for one participant.

The group’s VM profile showed strong orange values with little green or yellow resonance

and limited blue tolerance. Interviewees critiqued centralized decision-making and

described the SAFe environment as overly structured. These insights, while limited,

indicate structural friction and motivational constraint within the team.

A distinct pattern emerged across the teams: Higher subjective performance ratings of

team members corresponded to a stronger individual fit across psychological,

motivational, and cultural dimensions. Both high-performing Team H1 and H2

demonstrated value orientations that aligned well with SAFe structures. Team H1 had the

highest PJF, favorable Big Five configurations, and strong autonomy and competence

satisfaction. In contrast, Teams M1 and M2 showed greater misalignment, particularly

regarding autonomy needs, neuroticism, and low tolerance for blue values. The highest fit

was observed where psychological profiles, motivational needs, and value orientations

aligned most closely with SAFe values and structures. These contrasts lay the groundwork

for the next section, which summarizes emerging misalignment typologies.

4.2 Indicative typologies of misalignment

Building on the comparative patterns identified across teams, we derive three indicative

types of misalignments that explain the frictions observed in PJF under SAFe conditions.

Structural misalignment occurs when the formal autonomy expected in agile roles is not

matched by actual influence over decisions or process adaptations. This was evident in

Teams M1 and M2, where constrained perceived autonomy correlated with lower PJF

scores and unmet SDT needs.

Cultural misalignment refers to discrepancies between individual or team values and the

broader organizational context. In Team M1, low tolerance for blue values conflicted with

SAFe’s structural rigor, undermining motivational coherence despite shared green

aspirations.

78 Ninja Leikert-Boehm et al.

Developmental misalignment is related to the maturity of a team member’s value system

and their psychological readiness for demands of agile work. Elevated neuroticism, limited

openness, and low tolerance for complexity indicate difficulty engaging with participative,

self-organizing roles. This is most evident in mid-performing Teams M1 and M2.

These types of misalignments often intersect. Structural constraints can intensify cultural

friction, and both may amplify developmental tension. Together, they help explain why,

despite operating under formally equivalent SAFe conditions, teams experience

misalignments.

5 Discussion and implications for future work

5.1 Theoretical implications

This study extends classical PJF theory [Ed91] by incorporating personality traits [Mc08],

motivational needs [De00], and value system alignment [Be14]. In scaled agile

environments like SAFe [Kn20], perceived fit depends not only on capability match but

also on psychological and developmental coherence.

Our findings show that personality alignment alone is insufficient for high perceived fit.

Even individuals with favorable traits – e.g., conscientiousness, agreeableness, and

openness [Em22] – reported low fit when SDT needs were unmet [De00] or when cultural

values diverged from team and organizational norms [Gr74]. Conversely, high SDT

satisfaction did not guarantee fit when value dissonance was present [Be14]. This

underscores the importance of interaction effects between traits, needs, and values.

Developmental and cultural dimensions also shape SAFe-related role experiences. Low

tolerance for blue values (structure, control) can clash with SAFe’s standardized processes

[Ed22], while limited resonance with green or yellow values (collaboration, systemic

thinking) can hinder participation in agile rituals [La15]. In our study, these misalignments

manifested as demotivation, role ambiguity, or overload.

Together, these insights call for multi-layered fit models in demanding agile contexts.

These models could incorporate Big Five traits, SDT, Spiral Dynamics, and

developmental theory to account for differences in engagement and performance among

structurally similar teams.

5.2 Practical implications

The findings highlight a need for better diagnostic mechanisms in agile practice. Current

SAFe implementations lack tools to identify person-role misalignments early or

systematically. The contrast between high-fit (Team H1) and mid-fit teams (M1 and M2)

suggests that psychological and cultural diagnostics can uncover friction points that may

otherwise go unnoticed.

Fit for Agility? Exploring Person-Job Fit in SAFe Teams 79

Structural design and role clarity are also critical. Teams M1 and M2 encountered

challenges when standardized roles and ceremonies conflicted with autonomy needs or

developmental readiness. These findings suggest the need for differentiated autonomy

within SAFe roles – some individuals benefit from clear boundaries, while others require

more decision latitude. Team H1’s adaptive approach to SAFe rituals illustrates how

structural flexibility can enhance fit without compromising coordination.

Finally, the study suggests benefits of integrating psychological and value-based

assessments into team formation, role design, and development practices. Used as a

periodic pulse check, combined instruments (e.g., Big Five inventories, SDT-based need

assessment, Spiral Dynamic profiles) can inform two complementary intervention paths

for HR, agile coaches, and leadership: (i) individual-focused measures (coaching, targeted

upskilling, role negotiation) to improve person-job fit; and (ii) structural adaptations of

SAFe practices (e.g., calibrated decision rights, ceremony cadence, delegation levels) to

better fit team profiles. This approach aligns individuals with agile roles that suit their

psychological makeup and cultural orientation, thereby promoting a more human-centered

approach to agility.

5.3 Limitations and future research

The exploratory design of the study and its small sample size limit the generalizability of

the findings. Variations in participation, team purpose and scope, and maturity may have

influenced the results. Team H2 lacked psychological data, limiting comparative depth.

Aggregated VM profiles may obscure intra-team variance; moreover, the assessment is a

commercially developed instrument without full psychometric validation, which

represents a methodological limitation. Performance ratings were provided by Scrum

Masters and are subjective; survey measures of motivation and fit are self-reported and

context-sensitive.

Future research should validate and extend these findings using larger, more diverse

samples and consistent, multi-informant designs. It should also examine potential

conceptual overlaps between constructs. Comparative studies across frameworks (e.g.,

SAFe vs. Large-Scale Scrum (LeSS)) could clarify how psychological diversity interacts

with different scaling logics. Furthermore, fit accuracy and misalignment should be linked

to specific outcome variables – such as delivery speed, quality, and resource utilization –

as well as additional performance measures, such as the validated Agile Teamwork

Effectiveness Model [St22].

We also propose a design science stream aimed at developing and evaluating a diagnostic

tool that integrates personality traits, motivational needs, and value-based fit indicators.

Such a tool could support agile coaches and organizational developers by enabling pulse

checks, role adaptation, and psychologically informed interventions. For example, regular

feedback loops with individuals and teams could help align roles with evolving needs and

strengthen sustainable scaled agility. This would provide a more robust empirical basis for

designing adaptive organizational structures and targeted support measures.

80 Ninja Leikert-Boehm et al.

6 Conclusion

This case study highlights the importance of psychological, motivational, and

developmental factors in the success of agile transformations. Although frameworks such

as SAFe offer structural guidance for scaling agility, their effectiveness depends on how

well roles, values, and collaboration models align with the individuals enacting them.

By integrating personality traits, motivational needs, and value orientations, we

demonstrate that PJF is a central lever for sustainable agility. Our findings show that a

high level of fit (RQ1) is achieved when individual traits align with autonomy-supportive

conditions and team values. Conversely, structural rigidity and cultural misalignment

within SAFe settings (RQ2) often reduce perceived fit and performance. Misalignments –

whether structural, cultural, or developmental – can disrupt engagement, hinder autonomy,

and erode team cohesion, even in mature agile settings.

Therefore, agile transformations should move beyond competence-based role assignment.

Sustainable agility requires human-centered diagnostics and flexible role designs that

account for individual differences. This study offers a starting point for developing tools

and strategies that integrate psychological diversity into agile transformation practice.

Acknowledgements

We would like to thank ValueMatch, and Auke van Nimwegen in particular, for their

support in conducting and analyzing the Spiral Dynamics VM survey.

References

[As07] Ashton, M. C.; Lee, K.: Empirical, Theoretical, and Practical Advantages of the

HEXACO Model of Personality Structure. In: Personality and Social Psychology

Review, Bd. 11, Nr. 2, S. 150–166, 2007.

[Be14] Beck, D. E.; Cowan, C. C.: Spiral Dynamics: Mastering Values, Leadership and Change.

John Wiley & Sons, 2014.

[Be25] Beck, K. et al.: Manifesto for Agile Software Development. Agile Alliance.

https://agilemanifesto.org, Stand: 05.06.2025.

[Br02] Brkich, M. et al.: A Global Self-Report Measure of Person-Job Fit. In: European Journal

of Psychological Assessment, Bd. 18, Nr. 1, S. 43–51, 2002.

[Co10] Cook-Greuter, S. R.: Postautonomous ego development: a study of its nature and

measurement, Dissertation series. Integral Publishers, 2010.

[De00] Deci, E. L.; Ryan, R. M.: The „What“ and „Why“ of Goal Pursuits: Human Needs and

the Self-Determination of Behavior. In: Psychological Inquiry, Bd. 11, Nr. 4, S. 227–

268, 2000.

Fit for Agility? Exploring Person-Job Fit in SAFe Teams 81

[De07] DeRue, D. S.; Morgeson, F. P.: Stability and change in person-team and person-role fit

over time: The effects of growth satisfaction, performance, and general self-efficacy. In:

Journal of Applied Psychology, Bd. 92, Nr. 5, S. 1242–1253, 2007.

[Di16] Dikert, K. et al.: Challenges and success factors for large-scale agile transformations: A

systematic literature review. In: Journal of Systems and Software, Bd. 119, S. 87–108,

2016.

[Di23] Digital.ai: 16th State of Agile Report. https://digital.ai/resource-center/analyst-

reports/state-of-agile-report/. Stand: 09.01.2023.

[Ed22] Edison, H. et al.: Comparing Methods for Large-Scale Agile Software Development: A

Systematic Literature Review. In: IEEE Transactions on Software Engineering, Bd. 48,

Nr. 8, S. 2709–2731, 2022.

[Ed91] Edwards, J. R.: Person-job fit: A conceptual integration, literature review, and

methodological critique. In (Cooper, C. L.; Robertson, I. T.): International Review of

Industrial and Organizational Psychology. Bd. 6, John Wiley & Sons, Oxford, England,

S. 283–357, 1991.

[Ei07] Eisenhardt, K. M.; Graebner, M. E.: Theory Building From Cases: Opportunities and

Challenges. In: Academy of Management Journal, Bd. 50, Nr. 1, S. 25–32, 2007.

[Em22] Emmerich, P. et al.: Three Personality Trait Combinations for Agile Employees: The

Relationship Between the Big Five and Agile Mindset. In: ICIS 2022 Proceedings, S. 1–

17, 2022.

[Gr74] Graves, C. W.: Human Nature Prepares for a Momentous Leap. In: The Futurist, Bd. 8,

Nr. 2, S. 72–87, 1974.

[Ho20] Horlach, B.; Drechsler, A.: It’s Not Easy Being Agile: Unpacking Paradoxes in Agile

Environments. In (Paasivaara, M.; Kruchten, P.): Agile Processes in Software

Engineering and Extreme Programming – Workshops XP 2020. Lecture Notes in

Business Information Processing, Bd. 396, Springer, S. 182–189, 2020.

[Hu22] Hussain, W. et al.: How Can Human Values Be Addressed in Agile Methods? A Case

Study on SAFe. In: IEEE Transactions on Software Engineering, Bd. 48, Nr. 12, S.

5158–5175, 2022.

[Il91] Ilgen, D. R.; Hollenbeck, J. R.: The structure of work: Job design and roles. In:

Handbook of Industrial and Organizational Psychology, Vol. 2, 2nd ed. Consulting

Psychologists Press, Palo Alto, CA, US, S. 165–207, 1991.

[Jo99] John, O. P.; Srivastava, S.: The Big-Five Trait Taxonomy: History, Measurement, and

Theoretical Perspectives, University of California, Berkeley, S. 102–138, 1999.

[Ke98] Kegan, R.: In Over Our Heads: The Mental Demands of Modern Life. Harvard

University Press, 1998.

[Kn20] Knaster, R.; Leffingwell, D.: SAFe 5.0 Distilled: Achieving Business Agility with the

Scaled Agile Framework. Addison Wesley Professional, 2020.

[La15] Laloux, F.: Reinventing Organizations. C. H. Beck, 2015.

[Lo97] Loevinger, J.: Chapter 8 – Stages of Personality Development. In (Hogan, R. et al.):

Handbook of Personality Psychology. Academic Press, San Diego, S. 199–208, 1997.

82 Ninja Leikert-Boehm et al.

[Mc08] McCrae, R. R.; Costa, P. T.: The Five-Factor Theory of Personality. In (John, O. P. et

al.): Handbook of Personality: Theory and Research. 3. Aufl., Guilford Press, New York,

S. 159–181, 2008.

[My85] Myers, I. B.; McCaulley, M. H.: Manual: A Guide to the Development and Use of the

Myers-Briggs Type Indicator. 2. Aufl., Consulting Psychologists Press, Palo Alto, 1985.

[Ne99] Neuman, G. A. et al.: The Relationship between Work-Team Personality Composition

and the Job Performance of Teams. In: Group & Organization Management, Bd. 24, Nr.

1, S. 28–45, 1999.

[Ny22] Nyandongo, K. M.; Madumo, M. G.: The Adoption of the Scaled Agile Framework

(SAFe) in Non-Agile Organizations. In: 2022 IEEE 28th International Conference on

Engineering, Technology and Innovation (ICE/ITMC) & 31st International Association

for Management of Technology (IAMOT) Joint Conference, S. 1–8, 2022.

[Ra14] Rammstedt, B. et al.: Big Five Inventory (BFI-10). In: Zusammenstellung

sozialwissenschaftlicher Items und Skalen (ZIS). ZIS – GESIS Leibniz Institut für

Sozialwissenschaften, 2014.

[Ro07] Roberts, B. W. et al.: The Power of Personality: The Comparative Validity of Personality

Traits, Socioeconomic Status, and Cognitive Ability for Predicting Important Life

Outcomes. In: Perspectives on Psychological Science, Bd. 2, Nr. 4, S. 313–345, 2007.

[St22] Strode, Strode, D.; Dingsøyr, T.; Lindsjørn, Y.: A Teamwork Effectiveness Model for

Agile Software Development. In: Empirical Software Engineering, Bd. 27, Nr. 2, 2022.

[To04] Torbert, W. R.: Action Inquiry: The Secret of Timely and Transforming Leadership.

Berrett-Koehler Publishers, 2004.

[Ul22] Uludag, O. et al.: Revealing the State of the Art of Large-Scale Agile Development

Research: A Systematic Mapping Study. In: Journal of Systems and Software, Bd. 194,

111473, 2022.

[Va10] Van den Broeck, A. et al.: Capturing Autonomy, Competence, and Relatedness at Work:

Construction and Initial Validation of the Work-related Basic Need Satisfaction Scale.

In: Journal of Occupational and Organizational Psychology, Bd. 83, Nr. 4, S. 981–1002,

2010.

[Ye23] Yeman, R. J.; Malaiya, Y. K.: Comparison of Agile Scaling Frameworks. In:

Proceedings of the 2023 6th International Conference on Information Science and

Systems, ICISS ’23, S. 51–57, 2023.

[Yi18] Yin, R. K.: Case Study Research and Applications: Design and Methods. 6. Aufl.,

SAGE, Los Angeles, 2018.

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 83

Einsatz agiler Projektmanagementmethoden in KMU: Eine

qualitative Untersuchung in der Maschinen- und Anlagen-

bau-Branche

Elisabeth Schwarz1 und Timm Eichenberg2

Abstract: Agile Projektmanagementmethoden bieten Unternehmen die Möglichkeit, flexibel auf

Marktveränderungen und Kundenanforderungen zu reagieren. Während Großunternehmen bereits

umfassend agile Ansätze nutzen, stehen kleine und mittlere Unternehmen (KMU) vor besonderen

Herausforderungen bei deren Implementierung. Diese qualitative Studie untersucht anhand von Ex-

perteninterviews die spezifischen Hürden, Erfolgsfaktoren und Anpassungsbedarfe agiler Projekt-

managementmethoden in KMU der Maschinen- und Anlagenbau-Branche. Die Ergebnisse zeigen,

dass agile Projektmanagementmethoden selten zum Einsatz kommen und Gründe dafür in begrenz-

ten Ressourcen, fehlendem Methodenwissen und traditionellen Unternehmensstrukturen liegen,

während flache Hierarchien und kurze Entscheidungswege durchaus Potenziale für den Einsatz agi-

ler Projektmanagementmethoden in KMUs bieten.

Keywords: Agiles Projektmanagement, KMU, Mittelstand, Maschinen- und Anlagebau

1 Einleitung: Agiles Projektmanagement als Reaktion auf zuneh-

mende Marktdynamik

Innovationen sowie Prozessoptimierungen sind für Unternehmen essenziell, um langfris-

tig wettbewerbsfähig zu bleiben. Neue Produkte, Dienstleistungen und effizientere Res-

sourcennutzung werden daher zunehmend über Projekte realisiert [Ol98, BW09]. Aller-

dings scheitern 50 bis 80 % der Projekte entweder indem sie vorzeitig abgebrochen werden

oder die geplanten Vorgaben in Bezug auf Zeit, Budget oder Umfang überschreiten

[Ko06]. Zur Reduktion dieser Misserfolgsquote haben vor allem Großunternehmen in den

letzten Jahrzehnten ein professionelles Projektmanagement (PM) oder gar ein Multipro-

jektmanagement (MPM) etabliert [MM13, GEP24, EPW24]. Neben klassischen, planba-

sierten PM-Vorgehensmodellen kommen zunehmend agile PM-Vorgehensmodelle zum

Einsatz.

Auch kleine und mittlere Unternehmen (KMU) müssen zunehmend flexibel und reakti-

onsschnell agieren, um ihre Marktpräsenz und Wettbewerbsfähigkeit zu sichern [BC09].

KMU spielen dabei für die deutsche Volkswirtschaft eine entscheidende Rolle. Sie sind

ein zentraler Bestandteil der deutschen Wirtschaft: Neben ihrer Rolle als Zulieferer für

Großunternehmen erwirtschaften die 2,5 Millionen mittelständischen Unternehmen 42 %

der Bruttowertschöpfung und beschäftigen über die Hälfte der Erwerbstätigen in Deutsch-

land [He09, St25]. Hinsichtlich des Einsatzes von Projektmanagement zeigen sich jedoch

Unterschiede zu großen Unternehmen: Einer Studie der GPM Deutsche Gesellschaft für

1 elisabeth_schwarz@gmx.de

2 Hochschule Weserbergland, Fachbereich Wirtschaft, Am Stockhof 2, 31785 Hameln, eichenberg@hsw-ha-

meln.de

84 Elisabeth Schwarz und Timm Eichenberg

Projektmanagement zufolge setzen KMUs etwa weniger stark auf Projekte, um ihre Un-

ternehmensstrategie umzusetzen, als Großunternehmen dies tun [GEP23]. KMU nutzen

im Rahmen ihres Projektmanagements agile Methoden in einem deutlich geringen Maß

als Großunternehmen. Einer Studie zufolge betrachten zwei Drittel der befragten KMU

Agilität als strategisches Thema, während sie bei einem Drittel keine Rolle spielt – davon

kennt etwa die Hälfte Agilität nicht, die andere Hälfte sieht keinen Nutzen darin; 80 %

dieser Unternehmen erwarten auch in den nächsten fünf Jahren keine Relevanz für das

Thema [SJ19]. Auch erfolgt die Anwendung oft weniger strukturiert oder ohne klare Me-

thodik. Ein wesentlicher Grund vermag darin zu liegen, dass agile Methoden primär für

Großunternehmen entwickelt wurden [Br09]. Versuche, diese Frameworks auf KMU zu

übertragen, stoßen häufig auf strukturelle Herausforderungen. Zusätzlich erschweren spe-

zifische Merkmale von KMU die Anwendung agiler Methoden in Projekten, wie beispiels-

weise die begrenzt vorhandenen personellen und finanziellen Ressourcen [DBT25] oder

die Tatsache, dass in vielen KMU Projekte oft als Zusatzaufgabe neben dem Tagesge-

schäft laufen. Dabei weisen viele KMU optimale Voraussetzungen auf, um agile PM-Me-

thoden erfolgreich einzusetzen, verfügen sie doch aufgrund ihrer überschaubaren Größe –

sowohl in Bezug auf die Anzahl der Mitarbeiter als auch ihrer Hierarchiestufen – über

flexiblere und kürzere Rückkopplungsprozesse [Br09, Si17].

Exemplarisch wird in diesem Beitrag die Branche des Maschinen- und Anlagenbaus be-

trachtet, da dies der größte Industriezweig Deutschlands ist und als Schlüsselbranche der

deutschen Wirtschaft zählt [De21]. Auch zeichnet sich dieser Sektor durch eine hohe In-

novationsfähigkeit aus und setzt eine Vielzahl an Auftragseinzelfertigungen sowie kom-

plexen Projekten um [Bu23, St16]. Ebenfalls kann vermutet werden, dass der Einsatz agi-

ler Methoden in dieser Branche noch nicht so weit verbreitet ist wie in KMU der IT-Bran-

che, weswegen einer Untersuchung über den Einsatz agiler Methoden im Rahmen von

Projekten in dieser Branche untersuchenswert scheint. Ziel dieses Beitrags ist es daher,

die folgende Forschungsfrage zu beantworten:

Welche Faktoren beeinflussen den Einsatz agiler Projektmanagementmethoden in kleinen

und mittleren Unternehmen der Maschinen- und Anlagenbau-Branche?

Hierzu werden zunächst die wesentlichen theoretischen Grundlagen beleuchtet, anschlie-

ßend wird das Untersuchungsdesign vorgestellt. Darauf aufbauend werden die Ergebnisse

dargestellt. Das Fazit geht schließlich auf Implikationen für die Praxis ein.

2 Theoretischer Grundlagen des agilen Projektmanagements in

KMU

2.1 Grundlagen und Klassifikationen von KMU

KMU-Definitionen basieren auf qualitativen und quantitativen Kriterien und variieren je

nach Institution. Das Statistische Bundesamt und die EU-Kommission definieren KMU

anhand quantitativer Faktoren wie der Anzahl der Mitarbeiter und dem Jahresumsatz

(siehe Tabelle 1) [St25, Am03]. Das Bonner Institut für Mittelstandsforschung (IfM) setzt

die Grenze für Großunternehmen bei 500 Beschäftigten [If23]. Das Europäische Kompe-

tenzzentrum für angewandte Mittelstandsforschung (EKAM) definiert Unternehmen mit

Einsatz agiler Projektmanagementmethoden in KMU 85

bis zu 3000 Beschäftigten und einem Jahresumsatz von 600 Millionen Euro noch als KMU

[ID19].

KMU lassen sich zusätzlich nach Branche sowie Produkt- und Dienstleistungsangebot

klassifizieren [Ro05]. In der Europäischen Union erfolgt die Klassifikation von Unterneh-

men nach Wirtschaftsbereichen anhand des NACE-Codes (Nomenclature générale des

Activités économiques dans les Communautés Européennes) [IS19]. Im Rahmen des Bei-

trags wird die KMU-Definition des IfM verwendet, da diese Klassifizierung am häufigsten

genutzt wird [Si17].

Anzahl der Mitarbeiter

Jahresumsatz

Kleinstunternehmen

Bis 9 MA

Bis 2 Mio. €

Kleine Unternehmen

Bis 49 MA

Bis 10 Mio. €

Mittlere Unternehmen

Bis 249 MA

Bis 499 MA (IfM)

Bis ca. 3000 MA (EKAM)

Bis 50 Mio. €

600 Mio. € (EKAM)

Großunternehmen

Über 249 MA

Ab 500 MA (IfM)

über 3000 MA (EKAM)

Über 50 Mio. €

Über 600 Mio. € (EKAM)

Tab. 1: Größenklassifizierung von KMU [St25, Am03, If23, ID19]

2.2 Agiles Projektmanagement in KMU

Die Literaturrecherche umfasste einen Vergleich empirischer Studien zum Themengebiet,

welche nachfolgend zusammengefasst dargestellt werden. Eine ausführliche Übersicht

bietet Tabelle 4 im Anhang. KMU stehen bei der Anwendung agiler PM-Methoden vor

mehreren Herausforderungen. Besonders häufig genannt werden Budgetüberschreitungen,

ein hoher Abstimmungsaufwand und eine unzureichende Dokumentation [Kr22]. Aber

auch die Merkmale und Rahmenbedingungen der KMU wie begrenzte finanzielle und per-

sonelle Ressourcen, die häufig traditionellen Einstellungen und Abläufe sowie die Unter-

nehmenskultur können die Nutzung agiler Ansätze erschweren [Br09]. Auch muss die Be-

reitschaft (und Möglichkeit) gegeben sein, eventuell neue Mitarbeiter einzustellen, da auf-

grund der vollständigen Integration der Teammitglieder im agilen PM vorher zu erledi-

gende Aufgaben nun anderweitig bearbeitet werden müssen [St11a, St11b, Zi20].

Die Einführung agiler Methoden erfordert oft einen tiefgreifenden kulturellen Wandel.

Insbesondere das Aufbrechen etablierter Hierarchien, traditioneller Arbeitsweisen und der

Unternehmenskultur stellt eine Herausforderung dar [Ba18]. Dabei kann es bei Mitarbei-

tern und Führungskräften zu Widerständen kommen, wenn beispielsweise Machtverlust,

der Wegfall klassischer Karrierewege oder grundlegende Veränderungen ihrer Arbeits-

weise befürchten [Mi22, St11b].

KMU pflegen in der Regel einen engen Kontakt zu ihren Kunden und reagieren flexibel

auf deren Anforderungen, was den Einsatz agiler Methoden prinzipiell unterstützen kann.

Bei Unternehmen, in denen das nicht der Fall ist, kann es eine Herausforderung sein, Un-

ternehmensstrukturen zu öffnen und den Kunden stärker in den Fokus von agilen Projek-

ten zu rücken. Agile Projekte können schnelle Änderungen erfordern, um auf Kunden-

86 Elisabeth Schwarz und Timm Eichenberg

feedback zu reagieren. KMU müssen generell effektive Methoden entwickeln, um sicher-

zustellen, dass Projekte erfolgreich abgeschlossen werden [Zi20].

Agilität und die Verwendung agiler Methoden haben sich in deutschen Unternehmen noch

nicht flächendeckend durchgesetzt [KN08]. Studien zeigen zwar, dass agile Methoden zu

besseren Projektergebnissen, kürzeren Markteinführungszeiten, höherem Innovationsfo-

kus, gesteigerter Effizienz und reduzierten Risiken führen [Ho20, SJ19]. Studienerkennt-

nisse zeigen ebenfalls, dass auch weiche Faktoren wie Selbstorganisation, gemeinsame

Verantwortungsübernahme und Transparenz durch agile Methoden verbessert werden:

Die Studie „Agile Entwicklung mechatronischer Systeme“ lässt eine Korrelation zwischen

Projekterfolg und Selbstorganisation erkennen und zeigt auf, „dass der beobachtete Pro-

jekterfolg in einem stark durch Instabilität geprägten Umfeld mit dem Grad der Selbstor-

ganisation zunimmt“ [MI22].

In KMU werden agile Methoden meist selektiv eingesetzt und mit klassischen PM-Me-

thoden kombiniert [KN08, SJ19], was mit dem empirisch zu beobachtenden Trend hin zu

hybriden Ansätzen des Projektmanagements korrespondiert [Pm24]. Eine Übernahme agi-

ler Methoden „nach Lehrbuch“ erscheint in den meisten Fällen nicht zielführend, vielmehr

sollten diese in KMU kontextspezifisch angepasst werden, was mit einem hohen Aufwand

einhergeht [Ni21]. Auch besteht eine Diskrepanz zwischen dem Bestreben „agil zu sein“

und tatsächlich gelebter Agilität im Unternehmen [Zi20]. Als größte Herausforderungen

für den erfolgreichen Einsatz agiler Methoden werden oftmals der Führungsstil, das Top-

Management, die Unternehmenskultur oder Barrieren durch interne Prozesse genannt

[Ho20, Zi20, SJ19]. Dabei sind bei einem Großteil des Top-Managements agile Metho-

denkompetenzen bekannt und vorhanden [Zi20].

3 Methodische Vorgehensweise der empirischen Studie

Zur Beantwortung der Forschungsfrage wurde eine qualitative Untersuchung durchge-

führt. Die Analyse bestehender Studien zeigte, dass bisher vorwiegend quantitative An-

sätze verwendet wurden. Durch den gewählten qualitativen Ansatz soll eine neue Perspek-

tive eingenommen und zusätzliche Erkenntnisse gewonnen werden [KL24].

Die empirische Studie basiert auf einem Einzelfall-Design [Yi17, Ma23]. Als Fall wurden

KMU in der Maschinen- und Anlagenbau-Branche untersucht. Im Rahmen der Untersu-

chung wurden zwei Expertengruppen definiert. Die erste Gruppe umfasst Projektverant-

wortliche, darunter Projektmanager, Projektleiter und Geschäftsführer verschiedener Un-

ternehmen. Die zweite Expertengruppe setzt sich aus Projektmanagement- und Unterneh-

mensberatern sowie Wissenschaftlern zusammen. Ihre Interviews dienten dazu, die Aus-

sagen der ersten Gruppe zu ergänzen und eine umfassendere Einschätzung der Situation

in KMU zu ermöglichen.

Die Datenerhebung erfolgte durch leitfadengestützte Experteninterviews, um das Prozess-

und Deutungswissen der Befragten systematisch zu erfassen. Es wurden teilstrukturierte In-

terviews geführt, denen Leitfäden zugrunde lagen [BLM25]. Die Interviewleitfäden wur-

den theoriebasiert auf Basis der vorhandenen Literatur erstellt [BLM25]. Die einzelnen

Einsatz agiler Projektmanagementmethoden in KMU 87

Interviews wurden persönlich über das Videokonferenztool Microsoft Teams von Ende Sep-

tember bis Anfang November 2023 durchgeführt. Die Dauer der Gespräche lag zwischen 30

und 70 Minuten; die Interviews wurden aufgezeichnet.

Die Kontaktaufnahme mit den Interviewpartnern erfolgte nicht-zufallsbasiert, da eine

Vielzahl an potenziellen Unternehmen gezielt angeschrieben wurde (<150). Zur Identifi-

zierung dienten digitale Branchenplattformen (wlw.de; kompass.com; firmeneintrag.cre-

dit.de; fmb-messe.de). Bei der Auswahl der Unternehmen für die Expertengruppe 1 wur-

den folgende Auswahlkriterien zugrunde gelegt: Die Unternehmen durften entsprechend

der KMU-Klassifikation des IfM Bonn nur maximal 499 Mitarbeiter beschäftigen. Außer-

dem wurde die Branchenzugehörigkeit entsprechend der deutschen Wirtschaftszweigklas-

sifikation geprüft (Wirtschaftsbereich C, 28 – Verarbeitendes Gewerbe, Maschinenbau,

[St08]). Die Rekrutierung der Interviewpartner erfolgte über LinkedIn, die Deutsche Ge-

sellschaft für Projektmanagement (GPM), die Industrie- und Handelskammer Hannover

sowie die IG Metall Niedersachsen und Sachsen-Anhalt. In der Expertengruppe 1 wurden

acht Geschäftsführer und Projektmanager von verschiedenen Unternehmen befragt. In der

Expertengruppe 2 wurden sechs Fachexperten (Unternehmensberater und Wissenschaft-

ler) interviewt. Diese wurden auf Basis der vorhandenen Literatur und des aktuellen For-

schungsstandes ausgewählt und ebenfalls gezielt angeschrieben. Die Interviewpartner die-

ser Gruppe haben praktische Erfahrungen als Projektmanager in verschiedenen Unterneh-

men und unterstützen KMU, aber auch größere Unternehmen, bei der Implementierung

und Optimierung von klassischem und agilem PM. Ein Teil der Experten ist zudem in der

Maschinen- und Anlagenbau-Branche beratend tätig. Mit insgesamt 14 Interviews wurde

eine theoretische Sättigung der Interviewpartner erreicht, sodass die Datenerhebung da-

raufhin abgeschlossen wurde [DB23, BLM25, Ri23].

Im Zuge der Datenaufbereitung wurden die Interviews wörtlich mit Übertragung in normales

Schriftdeutsch transkribiert und in die Software MaxQDA übertragen [Ma23, DB23]. Für

die Datenauswertung wurde auf die qualitativen Inhaltsanalyse nach Kuckartz zurückge-

griffen [Ku22, KR20]. In einem deduktiv-induktivem Vorgehen wurde ein Kategoriensys-

tem entwickelt. Zuerst wurden Hauptkategorien anhand theoretischer Grundlagen und un-

abhängig von den erhobenen Daten ermittelt [Ku22]. Im zweiten Durchlauf entstanden

anhand des Materials Unterkategorien, die das Kategoriensystem verfeinerten. In einem

dritten Durchlauf wurde das Kategoriensystem weiter verfeinert, Kategorien zusammen-

gefasst und vereinzelt Textstellen umcodiert. Das finale Kategoriensystem umfasste 5 Ka-

tegorien, 28 Unterkategorien und 780 Codes. Nachfolgend werden Auszüge der durchge-

führten Untersuchung dargestellt.

Zur Sicherstellung der Qualität der Untersuchung wurden etablierte Gütekriterien qualitati-

ver Forschung nach Mayring und Kuckartz angewendet, wie Verfahrensdokumentation, Re-

gelgeleitetheit, argumentative Absicherung, Nähe zum Gegenstand, kommunikative Vali-

dierung und Triangulation. [Ma23, Ku22]. Durch eine strukturierte, iterative Vorgehens-

weise, sorgfältige Dokumentation sowie die Einbeziehung unterschiedlicher Expertengrup-

pen wurde ein reflektierter, nachvollziehbarer und theoriegestützter Forschungsprozess ge-

währleistet.

88 Elisabeth Schwarz und Timm Eichenberg

4 Darstellung der Ergebnisse der empirischen Studie

4.1 Expertengruppe 1: Projektverantwortliche in KMU

Die Analyse der Interviews mit Expertengruppe 1 zeigt, dass die untersuchten KMU im

Bereich des Projektmanagements (PM) viele Gemeinsamkeiten aufweisen, sich jedoch in

einigen Aspekten unterscheiden. Diese Unterschiede werden im Folgenden kurz beschrie-

ben und in Tabelle 2 anhand normativer, strategischer und operativer Aspekte dargestellt.

Eine zentrale Erkenntnis der Analyse ist, dass lediglich eines der untersuchten KMU be-

reits agile PM-Methoden integriert hat und ein weiteres deren Einführung anstrebt. Nach

Angaben der Interviewpartner ist eine Projektabwicklung mit agilem PM in der Regel

nicht umsetzbar. Zudem zeigt sich, dass der Wissensstand über agile PM-Methoden in den

befragten KMU insgesamt eher gering ist.

Übereinstimmende Einschätzungen

der befragten Projektverantwortlichen

Divergierende Einschätzungen der be-

fragten Projektverantwortlichen

Normative

Ebene

•PM wirkt sich auf Zusammenarbeit

im Unternehmen aus

•KMU weisen hohe Flexibilität auf

•Enge Kundenbindung als Einfluss-

faktor auf das PM

•Mindset für Agilität und agile PM-

Methoden nicht vollumfänglich vor-

handen

•Einstellung gegenüber PM seitens

der Beschäftigten

Strategische

Ebene

•Aufträge werden in Form von Pro-

jekten abgewickelt

•Ressourcen begrenzt verfügbar

•PM-Kenntnisse sind vorrangig in

der Geschäftsführung vorhanden

•Projektleitung hat meist zusätzlich

Tätigkeiten in der Linie

•Unternehmen arbeiten in Projekten

sequenziell bzw. planbasiert. Agiles

PM ist so gut wie nicht verbreitet.

•PM-Vorgehensmodelle sind aus den

Unternehmen heraus selbst „ge-

wachsen“ und werden an Mitarbeiter

und Unternehmensstruktur ange-

passt

•Keine verpflichtende Anwendung

eines standardisierten PM

•Einsatzkriterien für PM-Methoden

•Teils unklare Abgrenzung und Defi-

nition Projekt und Auftrag

•Professionalität im PM schwankt

•Variierende Projektorganisationsfor-

men

•Unterschiedlicher Einfluss der Ge-

schäftsführung auf Projekte und de-

ren PM

•PM-Prozesse sind nur teilweise do-

kumentiert

•PM-Zertifizierungen von Mitarbei-

tern sind selten

Operative

Ebene

•Befugnisse der Projektleitung nur in

einem engen Handlungsspielraum

gegeben

•Offener, flexibler Umgang mit An-

forderungsänderungen je nach Um-

fang und Zeitpunkt

•Standardisierung und Dokumenta-

tion von Projektschritten

•Anlehnung an Frameworks

•Umgang mit Change-Requests

Einsatz agiler Projektmanagementmethoden in KMU 89

Tab. 2: Identifizierte Gemeinsamkeiten und Unterschiede im Umgang mit Projekten und der Anwen-

dung von Projektmanagement innerhalb der Expertengruppe 1 (Projektverantwortliche in KMU)

Die Projektabwicklung der untersuchten KMU zeichnet sich durch hohe Flexibilität, kurze

und direkte Kommunikationswege sowie eine enge Zusammenarbeit mit den Kunden aus

–wobei diese Zusammenarbeit vorrangig in der Angebots- und Konstruktionsphase statt-

findet. Die Einführung von Projektmanagement und die Etablierung eines Projektmana-

gers wirken sich sowohl positiv als auch negativ auf die allgemeine Projektabwicklung

sowie auf das Verhalten einzelner Mitarbeiter und die Zusammenarbeit zwischen Abtei-

lungen aus.

Allen befragten KMU ist gemein, dass sie Projekte und damit eine Form des Projektma-

nagements zur Abwicklung von Kundenaufträgen nutzen. Eine klare Abgrenzung zwi-

schen „Projekt“ und „Auftrag“ besteht jedoch nicht in allen Unternehmen. Hinsichtlich

der Organisationsstruktur setzen die untersuchten Unternehmen auf unterschiedliche For-

men – von der Matrix-Organisation bis hin zur Einfluss-Organisation. Eine reine Projekt-

organisation wird aufgrund der Unternehmensgröße und der damit verbundenen begrenz-

ten Ressourcen nicht praktiziert und zudem als kulturell unpassend empfunden.

Die Projektabwicklung in den KMU erfolgt größtenteils sequenziell, also planbasiert. Die

verwendeten Projektmanagement-Vorgehensmodelle sind meist organisch aus dem Un-

ternehmen heraus gewachsen. Dabei zeigt sich, dass die konkrete Umsetzung dieser Mo-

delle stark von den beteiligten Mitarbeitern abhängt und es keine verpflichtende Anwen-

dung oder übergreifende Governance gibt. Wie strukturiert der Prozess verläuft, ob er de-

finiert und dokumentiert ist, variiert ebenfalls zwischen den Unternehmen.

In der Praxis reagieren alle Unternehmen in gewissem Maße agil, insbesondere in der An-

gebots- und Konstruktionsphase. Nach Beginn der Produktionsphase sind Änderungen

zwar noch möglich, jedoch mit einem deutlich höheren Aufwand verbunden.

In Kleinst- und kleinen Unternehmen übernimmt häufig die Geschäftsführung die Projek-

tabwicklung. Wird ein Projektleiter eingesetzt, verfügt dieser meist nur über einen be-

grenzten Handlungsspielraum, der deutlich hinter dem zurückbleibt, was in der Literatur

oder in etablierten Projektmanagementstandards für diese Rolle vorgesehen ist. Zudem

übernehmen Projektleiter in den meisten Fällen neben ihren Projekttätigkeiten auch pri-

märe Aufgaben in der Linienorganisation.

Mit Blick auf die wesentlichen Zieldimensionen der Projekte wird übereinstimmend be-

richtet, dass der Projektumfang im Verlauf nicht angepasst wird. Stattdessen werden Ab-

striche meist bei Zeit- und Budgetvorgaben vorgenommen. Nur eines der befragten KMU

berichtet davon, Kundenprojekte planmäßig abzuschließen – allerdings unter erheblichem

Mehraufwand und mit zusätzlicher Wochenendarbeit für die Mitarbeiter.

•Faktoren Zeit und Budget werden

häufig überschritten; Umfang ist

feste Größe

•Selten kommen PM-spezifische

Tools zum Einsatz

90 Elisabeth Schwarz und Timm Eichenberg

4.2 Expertengruppe 2: Fachexperten aus Beratung und Wissenschaft

Die Ergebnisse der Interviews mit der zweiten Expertengruppe sind in Tabelle 3 zusam-

mengefasst und werden im Folgenden kurz erläutert.

Alle befragten Experten betonen die hohe Bedeutung von Projektmanagement und der

Projektabwicklung in KMU. Die Relevanz agiler Methoden nimmt dabei stetig zu, da

diese zunehmend in Unternehmen, Unternehmerverbänden und auf Konferenzen disku-

tiert werden. Nach Einschätzung der Experten stehen KMU unter wachsendem Druck,

schneller auf Marktveränderungen zu reagieren und mit Kunden sowie Partnern Schritt zu

halten. Auch der Generationswechsel in den Unternehmen trägt zum steigenden Interesse

an agilen Methoden bei.

Der aktuelle Einsatz agiler Methoden variiert je nach Branche deutlich: Während die IT-

Branche bereits als vergleichsweise agil wahrgenommen wird, besteht insbesondere im

Anlagen- und Maschinenbau noch erheblicher Nachholbedarf. In dieser Branche herrscht

unter den Experten Uneinigkeit darüber, ob agile Methoden sinnvoll einsetzbar sind.

Befürworter argumentieren, dass agile Methoden durch die Anpassung von „Ereignissen“

und „Artefakten“ an den KMU-Kontext sowie durch eine gezielte Skalierung erfolgreich

implementiert werden können. Kritiker hingegen halten den Einsatz agiler Methoden in

KMU dieser Branche für wenig zielführend oder gar nicht umsetzbar. Sie begründen dies

mit den spezifischen Anforderungen der Kunden sowie den besonderen Qualitätsstan-

dards, die mit dem Produkt Maschine/Anlage verbunden sind.

Übereinstimmende Einschätzungen der

befragten Fachexperten

Divergierende Einschätzungen der be-

fragten Fachexperten

Normative

Ebene

•Mindset und Verständnis für agile Me-

thoden und PM muss als Vorausset-

zung vorhanden sein

•Angepasste Führungskultur ist voraus-

setzend für Umsetzung agiler Metho-

den

•Effekte des Einsatzes von agilem PM

in Bezug auf weiche Faktoren wie

Transparenz, Kommunikation, Com-

mitment und Selbstorganisation

Strategische

Ebene

•PM nicht in Strategie verankert

•Geringe Ressourcenverfügbarkeit

•Organisationsstruktur beeinflusst PM

•Einsatzbereich agiler Methoden ge-

zielt wählen; je nach Projekt und Ein-

satzfeld sind klassische und/oder agile

Methoden sinnvoll

•Potenzial, agile Methoden einzuset-

zen, ist bei KMU in der Branche vor-

handen

•Multitasking zwischen Linien- und

Projektaufgaben kann die Effizienz

von PM einschränken

•Unterstützung von Externen bei der

Einführung agiler PM-Methoden

•Umfeld zwingt zu Einsatz agiler Me-

thoden

Einsatz agiler Projektmanagementmethoden in KMU 91

Tabelle 3: Identifizierte Gemeinsamkeiten und Unterschiede im Umgang mit Projekten und der An-

wendung von Projektmanagement in KMU innerhalb der Expertengruppe 2 (Beratung und

Wissenschaft)

Es zeigt sich, dass ein umfassendes Mindset und Verständnis für Projektmanagement im

Allgemeinen und für agile Methoden im Besonderen in KMU nicht flächendeckend vor-

handen sind. Dabei bieten KMU aufgrund ihrer Merkmale ein großes Potenzial für den

Einsatz agiler Methoden: Ihre höhere Flexibilität und die vergleichsweise kurzen, direkten

Kommunikationswege ermöglichen oft schnellere Reaktionen. Um agile Projektmanage-

mentmethoden erfolgreich einzuführen, ist jedoch eine Anpassung der Unternehmens- und

Führungskultur erforderlich.

Insbesondere das mittlere Management wird von den befragten Experten als entschei-

dende Hürde für die Implementierung und Anwendung agiler Methoden gesehen. Füh-

rungskräfte in dieser Ebene müssen daher gezielt von den Potenzialen agiler Ansätze über-

zeugt werden. Dies gestaltet sich jedoch oft herausfordernd, da die Auswirkungen agiler

Methoden vorrangig bei „weichen“ Faktoren wie Kommunikation, Transparenz und

Teamgefühl spürbar sind und weniger direkt bei „harten“ Kennzahlen wie Produktions-

oder Finanzdaten.

Die Experten sind sich einig, dass agile Methoden die Kommunikation, Transparenz sowie

das Commitment von Belegschaft und Kunden fördern. Zudem steigern sie die Mitarbei-

terzufriedenheit und das Teamgefühl. Ob sich agile Methoden jedoch positiv auf Faktoren

wie Zeitersparnis, Produktionsgeschwindigkeit oder Kosten auswirken, wird unterschied-

lich bewertet.

Ein weiteres Hemmnis ist die fehlende Verankerung von Projektmanagement in der Un-

ternehmensstrategie vieler KMU, wodurch Investitionen in dieses Thema häufig ausblei-

ben. Die Experten empfehlen übereinstimmend, Projekte in KMU in einer Matrix-Orga-

nisation durchzuführen, passende PM-Methoden entsprechend ihres Einsatzfeldes auszu-

wählen und diese nicht als Selbstzweck zu nutzen. Die Methoden sollten an das jeweilige

Unternehmen angepasst und als Leitplanken für das operative Handeln verstanden wer-

den.

Unterschiedlich bewertet wird, ob Mitglieder der Projektteams ausschließlich Projektauf-

gaben übernehmen oder zusätzlich auch Linientätigkeiten ausführen sollten. Während

„Multitasking“ einerseits als hinderlich für die Einhaltung der Projektziele in Bezug auf

Umfang, Zeit und Kosten angesehen wird, reduziert die Kombination von Projekt- und

Operative

Ebene

•Projektleitung braucht Unterstützung

der Unternehmensführung

•Implementierung agiler Methoden

braucht mehrere Jahre sowie Beglei-

tung durch ein Change Management

•Anpassung und Entwicklung der Me-

thodiken und Prozesse

•Parallele Anwendung von agilen und

klassischen Vorgehensweisen

•Einsatzmöglichkeit agiler Methoden

je nach Branche

•Klassisches PM ist oftmals Aus-

gangspunkt für agiles PM

92 Elisabeth Schwarz und Timm Eichenberg

Linienaufgaben andererseits den Kommunikationsaufwand. Ebenso gibt es unterschiedli-

che Ansichten darüber, ob agile Methoden auf einer klassischen PM-Struktur aufbauen

sollten oder ob dies nicht erforderlich ist. Auch der Nutzen externer Unterstützung bei der

Einführung agiler Methoden wird unterschiedlich eingeschätzt. Entscheidend sei dabei vor

allem das Wissen um die spezifischen Anforderungen der jeweiligen Branche und des

Unternehmens.

Da PM-Methoden je nach Einsatzfeld variieren können, ist auch der parallele Einsatz agi-

ler und planbasierter Methoden innerhalb eines Unternehmens möglich. Dies kann jedoch

zu gegenseitigen Behinderungen führen. Die Experten betonen daher, dass die Einführung

agiler Projektmanagementmethoden ein gezieltes Change Management erfordert und sich

über mehrere Jahre erstreckt. Besonders wichtig ist dabei, schrittweise ein gemeinsames

und einheitliches Verständnis des Vorgehensmodells innerhalb der Belegschaft zu etab-

lieren. Auf dieser Grundlage sollten die eingesetzten agilen Methoden kontinuierlich re-

flektiert, angepasst und weiterentwickelt sowie deren Einhaltung sichergestellt werden.

4.3 Identifizierte Herausforderungen und Rahmenbedingungen für die Imple-

mentierung agiler Projektmanagementmethoden in KMU der Maschinen-

und Anlagenbaubranche

Trotz vorteilhafter Rahmenbedingungen wie flachen Hierarchien, direkter Kommunika-

tion, kundenspezifischen Produkten und hoher Flexibilität werden agile Methoden für das

Management von Projekten in den untersuchten KMU der Maschinen- und Anlagenbau-

Branche kaum angewendet. Dies liegt vor allem an einer geringen Veränderungsbereit-

schaft, einer stark hierarchisch geprägten Unternehmenskultur und einem wenig ausge-

prägten agilen Mindset. Hinzu kommen begrenzte Ressourcen und volatile Marktbedin-

gungen, die die Implementierung zusätzlich erschweren.

Die untersuchten KMU agieren in Nischenmärkten und müssen sich deren spezifischen

Anforderungen anpassen. Ihre starke Abhängigkeit von einzelnen Auftraggebern und Zu-

lieferern sowie gesetzliche Vorgaben beeinflussen die Arbeitsweise und den Ressourcen-

einsatz erheblich. Verkürzte Produkt- und Maschinenlebenszyklen zwingen die Unterneh-

men zu einer Anpassung ihrer Produktionsweise, was ein verändertes Verständnis und

eine neue Denkweise der Belegschaft erfordert.

Die Einführung agiler PM-Methoden wird zudem durch begrenzte personelle, zeitliche

und finanzielle Ressourcen erschwert. Aus wirtschaftlichen Gründen finden Schulungen

in PM-Methoden seltener statt, und Implementierungsphasen werden möglichst kurz ge-

halten. In den meisten untersuchten KMU übernehmen Projektleiter und Projektteams ihre

Aufgaben zusätzlich zu Linienaufgaben, die häufig im Vordergrund stehen. Da Projekt-

leiter oft keinen direkten Zugriff auf Mitarbeiterressourcen haben und ihre Entscheidungs-

kompetenzen eingeschränkt sind, ist ihre Wirksamkeit begrenzt.

Um agiles Projektmanagement erfolgreich einzuführen, sind Veränderungen in der Unter-

nehmensstruktur und -kultur erforderlich. Dies hängt maßgeblich von der Veränderungs-

bereitschaft und -fähigkeit des Unternehmens und seiner Belegschaft ab. Die Untersu-

chung zeigt, dass die größten Herausforderungen darin bestehen, dass Führungskräfte und

Mitarbeiter die Veränderungen nicht nachvollziehen können, Widerstand leisten oder aus

Einsatz agiler Projektmanagementmethoden in KMU 93

Sorge um begrenzte Personalressourcen zögern. Zudem setzt der erfolgreiche Einsatz agi-

ler Methoden ein hohes Maß an Kompetenz der Mitarbeiter voraus – insbesondere im

Hinblick auf Selbstorganisation, Verantwortungsübernahme und ein agiles Mindset. In

diesem Zusammenhang können tradierte und stark ausgeprägte Organisations- und Ent-

scheidungsstrukturen die Einführung agiler Methoden erheblich behindern.

5 Diskussion der Ergebnisse

Die Ergebnisse der qualitativen Studie zeigen deutlich, dass agile Projektmanagementme-

thoden in KMU der Maschinen- und Anlagenbau-Branche anders als beispielweise in der

IT kaum systematisch eingesetzt werden. Zwar verfügen KMU über flache Hierarchien,

direkte Kommunikationswege und eine enge Kundenbindung – Merkmale, die aus Sicht

der Befragten grundsätzlich Potenzial für agile Arbeitsweisen bieten –, doch wird dieses

Potenzial bislang nur vereinzelt ausgeschöpft. Die meisten Unternehmen arbeiten weiter-

hin überwiegend sequenziell und planbasiert, wobei ihre Vorgehensweisen historisch ge-

wachsen und kaum formalisiert sind. Projektmanagement erfolgt in vielen Fällen ohne

verbindliche Standards und hängt stark von individuellen Personen ab.

Auffällig ist, dass sich zwischen den beiden befragten Gruppen Unterschiede in der Ein-

schätzung der Einsetzbarkeit agiler Methoden zeigen. Während die Projektverantwortli-

chen agile Ansätze vielfach als nicht praktikabel einschätzen oder ihnen wenig Wissen

darüber attestieren, betonen die externen Experten die grundsätzliche Umsetzbarkeit – so-

fern eine gezielte Anpassung an den KMU-Kontext erfolgt. Diese Diskrepanz verweist auf

eine mögliche Wahrnehmungslücke und unterstreicht die Relevanz von Kommunikation,

Schulung und externem Know-how bei Transformationsprozessen.

Ein weiterer zentraler Aspekt betrifft die Rolle der Projektleitung. In den meisten KMU

ist sie zusätzlich zur Linienfunktion in einer Position verankert und mit begrenzten Ent-

scheidungskompetenzen ausgestattet. Dies schränkt die Umsetzung komplexerer PM-An-

sätze – ob klassisch oder agil – erheblich ein. Auch die Experten betonen, dass die Pro-

jektleitung auf die aktive Unterstützung der Unternehmensführung angewiesen ist, um

überhaupt Veränderungen in der Methodik umzusetzen. Es wird zudem deutlich, dass der

Aufbau agiler Strukturen ein längerfristiger Veränderungsprozess ist, der – so der Tenor

beider Gruppen – nicht ohne strukturelle und kulturelle Anpassungen gelingen kann.

Fraglich bleibt, ob klassische agile Frameworks im Sinne eines „One-size-fits-all“-Ansat-

zes überhaupt sinnvoll auf KMU übertragbar sind oder ob es vielmehr kontextangepasste,

hybride Ansätze braucht, die mit den Ressourcen und Strukturen kleiner Unternehmen

kompatibel sind.

Die qualitative Methodik erlaubt tiefe Einblicke, erhebt aber keinen Anspruch auf Reprä-

sentativität und vermag die Heterogenität der KMU-Landschaft nur begrenz abzubilden.

Zukünftige Forschung sollte daher auch kontrastierende Fallbeispiele von KMU analysie-

ren, die agile Methoden bereits erfolgreich einsetzen, um übertragbare Erfolgsfaktoren

abzuleiten und bestehende Theorien auf ihre Passfähigkeit im Mittelstand zu überprüfen.

94 Elisabeth Schwarz und Timm Eichenberg

6 Fazit: Erkenntnisse und Implikationen für die Praxis

Im Kontext von KMU der Maschinen- und Anlagenbau-Branche zeigt sich, dass flexibles

Handeln, flache Hierarchien und eine starke Kundenorientierung bereits vorhanden sind –

und damit auch erste Ansätze sowie günstige Voraussetzungen für Agilität bestehen. Ei-

nige KMU arbeiten aufgrund ihrer projektbasierten Auftrags- und Produktentwicklung be-

reits agil, jedoch meist ohne eine systematische Vorgehensweise. Häufig fehlen zeitliche,

personelle und finanzielle Ressourcen, wodurch auch das erforderliche Know-how für ei-

nen konsequenten Transformationsprozess hin zu einer umfassenden und strukturierten

agilen Arbeitsweise nicht ausreichend vorhanden ist.

Um diesen Wandel erfolgreich umzusetzen, ist die Bereitschaft erforderlich, Unterneh-

menskultur, Strategie und Strukturen an agile Prinzipien anzupassen. Dies setzt zugleich

voraus, dass alle Stakeholder bereit sind, aktiv an den Veränderungen mitzuwirken: Die

Geschäftsführung muss Entscheidungsbefugnisse abgeben, die Belegschaft eigenverant-

wortlicher arbeiten, und auch die Kunden müssen bereit sein, das agile Vorgehen zu un-

terstützen.

Bei der Einführung und Anwendung agiler Methoden hat sich gezeigt, dass eine individu-

elle Anpassung an das Unternehmen, das jeweilige Projekt, das Produkt sowie die spezi-

fischen Rahmenbedingungen entscheidend ist. Die Einführung agiler Methoden ist ein

langfristiger Prozess, der von der Führungsebene vorgelebt und durch Change Manage-

ment-Maßnahmen unterstützt werden muss, um Mitarbeiter einzubinden und Widerstände

abzubauen [EB11].

Agiles Projektmanagement ist kein universelles Erfolgsrezept und sollte nicht zum Selbst-

zweck eingesetzt werden. Unter geeigneten Rahmenbedingungen bleiben klassische, plan-

basierte Vorgehensweisen eine sinnvolle Alternative. Gelingt eine Einführung, kann der

Einsatz agiler Methoden kleine und mittlere Unternehmen der betrachteten Branche bei

der Entwicklung innovativer, komplexer Produkte unterstützen und damit einen Beitrag

leisten, ihre Existenz in Zukunft zu sichern. Die Methoden des agilen Projektmanagements

bieten bei passender Umsetzung in der für die deutsche Wirtschaft so wichtige Gruppe

kleiner und mittelständischer Unternehmen im Maschinen- und Anlagenbau langfristig die

Möglichkeit, weiter in einer volatilen Welt zu bestehen, sich stärker an Kunden- und

Marktanforderungen zu orientieren und sich gegen die internationale Konkurrenz wettbe-

werbsfähig aufzustellen.

Literaturverzeichnis

[Am03] Amtsblatt der Europäischen Union: Empfehlung der Kommission vom 6. Mai 2003 be-

treffend die Definition der Kleinstunternehmen sowie der kleinen und mittleren Unter-

nehmen. https://eur-lex.europa.eu/legal-con-

tent/DE/TXT/PDF/?uri=CELEX:32003H0361, 2003, Stand: 28.03.2025.

[Ba18] Bause, K.: Vorgehensweisen, Möglichkeiten und Risiken in der Umstellung zum agilen

Projektmanagement. https://www.sosy-lab.org/Teaching/2017-WS-JurPM/Bause-Ausar-

beitung.pdf, 2018, Stand: 28.03.2025.

Einsatz agiler Projektmanagementmethoden in KMU 95

[BC09] Bergmann, L.; Crespo, I.: Herausforderungen kleiner und mittlerer Unternehmen. In

(Dombrowski, U.; Hermann, Ch.; Lacker, T.; Sonnentag, S., Hrsg.), Modernisierung

kleiner und mittlerer Unternehmen. Ein ganzheitliches Konzept, Springer, S. 5-29, 2009.

[BW09] Best, E.; Weth, M.: Geschäftsprozesse optimieren. Der Praxisleitfaden für erfolgreiche

Reorganisation, 3. Aufl., Gabler, 2009.

[Bu23] Bundesministerium für Wirtschaft und Klimaschutz: Wirtschaftsbranchen - Maschinen-

und Anlagenbau. https://www.bmwk.de/Redaktion/DE/Artikel/Branchenfokus/Indust-

rie/branchenfokus-maschinen-und-anlagenbau.html, 2023, Stand: 28.03.2025.

[BLM25] Bogner, A.; Littig, B.; Menz, W.: Interviews mit Experten. Eine praxisorientierte Ein-

führung, 2. Aufl., Springer VS, 2025.

[Br09] Braehmer, U.: Projektmanagement für kleine und mittlere Unternehmen. Das Praxisbuch

für den Mittelstand, 2. Aufl., Hanser, 2009.

[De21] Deutscher Sparkassen- und Giroverband e. V.: Branchenreport Maschinenbau, Deutscher

Sparkassen Verlag, 2021.

[DB23] Döring, N.; Bortz, J.: Forschungsmethoden und Evaluation in den Sozial- und Human-

wissenschaften, 6. Aufl., Springer, 2023.

[DBT25] Dubierry, R.; Binder, S.; Treude, S.: Strategisches Start-up- und Mittelstandsmanage-

ment: Handlungsempfehlungen, Praxisbeispiele und Toolvorlagen, Springer Gabler 2025

[EB11] Eichenberg, T.; Behse, M.: Change Management: Gesteuerter Wandel für eine vitale Un-

ternehmung. In. (Eggers, B.; Ahlers, F.; Eichenberg, T., Hrsg.): Integrierte Unterneh-

mungsführung, Gabler Verlag, S. 175-190, 2011.

[EPW24] Eichenberg, T.; Peuser, M.; Wolf, M.: Ergebnisse der Studie Projektportfolio Sustainabi-

lity Monitor 2024: Status Quo von Nachhaltigkeit als Kriterium im Projektportfolioma-

nagement deutscher Unternehmen. In: Projektmanagement aktuell, 35. Jg., H. 5, S. 63-

67, 2024.

[He09] Hermann, Ch.: Einleitung. In (Dombrowski, U.; Hermann, Ch.; Lacker, T.; Sonnentag,

S., Hrsg.), Modernisierung kleiner und mittlerer Unternehmen. Ein ganzheitliches Kon-

zept, Springer, S. 1-4, 2009.

[Ho20] Hochschule Koblenz: Status Quo (Scaled) Agile. 4. Studie zu Nutzen und Erfolgsfakto-

ren agiler Methoden. https://www.hs-koblenz.de/index.php?id=7169, 2020, Stand:

28.03.2025.

[GEP23] GPM Deutsche Gesellschaft für Projektmanagement; Projektifizierung 2.0. Zweite Mak-

roökonomische Vermessung der Projekttätigkeit in Deutschland, UVK 2023

[GEP24] GPM Deutsche Gesellschaft für Projektmanagement; Eichenberg, T.; Peuser, M.: Pro-

jektportfolio Sustainability Monitor 2024: Studie in der deutschen Unternehmenspraxis

mit Fokus auf die UN Sustainable Development Goals, UVK, 2024.

[If23] IfM Bonn: KMU-Definition des IfM Bonn. https://www.ifm-bonn.org/definitionen-

/kmu-definition-des-ifm-bonn, 2023, Stand: 28.03.2025.

[ID19] Ihlau, S.; Duscha, H.: Besonderheiten bei der Bewertung von KMU. Planungsplausibili-

sierung, Steuern, Kapitalisierung, 2. Aufl., Springer Gabler, 2019.

[IS19] Immerschitt, W.; Stumpf, M.: Employer Branding für KMU. Der Mittelstand als attrakti-

ver Arbeitgeber, 2. Aufl., Springer Gabler, 2019.

96 Elisabeth Schwarz und Timm Eichenberg

[KCB22] Kinkel, S.; Cherubini, E.; Beiner, S.: Betriebe in Deutschland nutzen zu wenig agile Me-

thoden. https://agilhybrid.de/blog/internationaler-vergleich-deutsche-unternehmen-hin-

ken-bei-der-entwicklung-digitaler-geschaeftsmodelle-hinterhere-unternehmen-und-die-

entwicklung-digitaler-geschaeftsmodelle/, 2022, Stand: 28.03.2025

[KL24] Krell, C.; Lamnek, S.: Qualitative Sozialforschung, 7. Aufl., Beltz, 2024.

[KN08] Kern, R.; Nagengast, J.: Projektmanagement 2008. Fakten und Trends zum Projektma-

nagement im deutschen Mittelstand, Haufe Akademie GmbH, 2008.

[Ko06] Köhler, P.: Prince 2. Das Projektmanagement-Framework, Springer, 2006.

[Kr22] Krause, M.: Agiles Projektmanagement der Fabrikplanung unter Unsicherheiten, Disser-

tation, Gottfried Wilhelm Leibniz Universität Hannover, TEWISS, 2022.

[Ku22] Kuckartz, U.: Qualitative Inhaltsanalyse. Methoden, Praxis, Computerunterstützung, 5.

Aufl., Beltz Juventa, 2022.

[KR20] Kuckartz, U.; Rädiker, S.: Computergestützte Analyse qualitativer Daten (CAQDAS). In

(Mey, G.; Mruck, K., Hrsg.), Handbuch Qualitative Forschung in der Psychologie. Band

2: Design und Verfahren, 2. Aufl., Springer, S. 813-834, 2020.

[MM13] Majer, Ch.; Miller, R.: Projektmanagement. In (Eschenbach, R.; Horak, Ch.; Meyer, M.;

Schober, Ch., Hrsg.): Management der Nonprofit-Organisation. Bewährte Instrumente

im praktischen Einsatz, 2. Aufl., Schäffer-Poeschel, S. 335-357, 2013.

[Ma23] Mayring, P.: Einführung in die qualitative Sozialforschung, 7. Aufl., Beltz Verlag, 2023.

[Mi22] Michalides, M.; Nicklas, S. J.; Weiss, S.; Paetzold, K.: Agile Entwicklung physischer

Produkte 2022: Eine Studie zum aktuellen Stand in der industriellen Praxis, Universität

der Bundeswehr München, https://athene-forschung.unibw.de/143371, 2022, Stand:

28.03.2025.

[Ni21] Nicklas, S. J.; Michalides, M.; Atzberger, A.; Weiss, S.; Paetzold, K.: Agile Entwicklung

physischer Produkte 2021: Eine Studie zum aktuellen Stand in der industriellen Praxis

während der COVID-19-Pandemie, Universität der Bundeswehr München,

https://athene-forschung.unibw.de/doc/139470/139470.pdf , 2021, Stand: 28.03.2025.

[Ol98] Olfert, K.: Projektmanagement, 10. Aufl., Kiehl NWB-Verlag, 1998.

[Pm24] Project Management Institute: Pulse of the Profession® 2024. The Future of Project

Work: Moving Past Office-Centric Models, 15th Edition, https://www.pmi.org/-/me-

dia/pmi/documents/public/pdf/learning/thought-leadership/pmi-pulse-of-the-profession-

2024-report.pdf?rev=c480c0b72ee8466eaba10132b614c5d7, 2024, Stand: 28.03.2025

[Ri23] Rick, J.: Problemzentrierte Interviews online und offline: eine methodische Reflexion. In

Forum Qualitative Sozialforschung / Forum: Qualitative Social Research, 24. Jg., H. 2,

2023.

[Ro05] Rößl, D.: Marketing für Klein- und Mittelbetriebe – Spezifische Betrachtungslinien im

Objektbereich. In: Holzmüller, H.; Schuh, A. (Hrsg.): Innovationen im sektoralen Mar-

keting. Festschrift zum 60. Geburtstag von Fritz Scheuch, Physica-Verlag, S. 143-160,

2005.

[SJ19] Schulke, A.; Jütte, S.: Kann der deutsche Mittelstand „agil“?, UBH Discussion Papers -

Business & Management, No. 1/2019, IUBH Internationale Hochschule,

https://www.econstor.eu/bitstream/10419/215760/1/1694327167.pdf , 2019, Stand:

28.03.2025

Einsatz agiler Projektmanagementmethoden in KMU 97

[Si17] Siegried, P.: Strategische Unternehmensplanung in jungen KMU: Problemfelder und Lö-

sungsansätze, De Gruyter Oldenbourg, 2017.

[St08] Statistisches Bundesamt: Klassifikation der Wirtschaftszweige. Mit Erläuterungen, 2008.

[St25] Statistisches Bundesamt: Kleine und mittlere Unternehmen. Branchen-Unternehmen/Un-

ternehmen/Kleine-Unternehmen-Mittlere-Unternehmen/_inhalt.html, 2025, Stand:

28.03.2025.

[St16] Stärk, J.: Agiles Projektmanagement im Anlagen- und Maschinenbau, Dissertation, Uni-

versität Hohenheim, Books on Demand, 2016.

[St11a] Steeger, O.: Mittelstand verbessert Projektmanagement in sehr kleinen Schritten:

Braucht der Mittelstand speziell zugeschnittene PM-Qualifizierung? In: Projektmanage-

ment aktuell, 22. Jg., H. 4, S. 20-21, 2011.

[St11b] Steeger, O.: Nur unter Druck verbessern viele Mittelständler ihr PM: Am Bewährten

möglichst wenig „rütteln“. In: Projektmanagement aktuell, 22. Jg., H. 4, S. 22-23, 2011.

[Yi17] Yin, R. K.: Case Study Research and Applications: Design and Methods, 6. Aufl., Sage

Publications, 2017

[Zi20] Zillmann, M.: Agile Transformation. Doing Agile versus Being Agile, Lünendonk-Son-

deranalyse, Lünendonk & Hossenfelder GmbH, 2020.

Anhang

Studie

Empirie/Metho-

dik

Untersuchungsgegen-

stand

Untersuchungsrelevante Kerner-

gebnisse

Projektmanage-

ment 2008 -

Fakten und

Trends zum

Projektmanage-

ment im deut-

schen Mittel-

stand 2008

[KN08]

Quantitative

Studie mit On-

line-Fragebogen

mit 32 Fragen

der vom 17.07.-

15.09.2008

Teilnehmende an Haufe

Akademie Seminaren

zum Thema PM, tätig

im IT-Bereich, mit Füh-

rungsverantwortung,

MA der Personalabtei-

lung, Unternehmens-

größe 100-1000 MA;

auf Online-Plattformen:

PM-Blogs und Informa-

tionsanbieter

www.competence-

site.de und die Exper-

tenseite www.projekt-

magazin.de.

PM spielt im Mittelstand unterge-

ordnete Rolle

PM ist nicht konsequent im Unter-

nehmensumfeld eingebettet, wird

„inselartig verstreut“ durchgeführt

Standards und Zertifizierungen sind

selten

PM wird on-the-job gelernt und

weist geringen Grad an Methoden-

nutzung auf.

Projektleiter und Teammitglieder

müssen multitaskingfähig sein, sind

in mehreren Projekten aktiv

Projekte werden neben Kernaufga-

ben ausgeübt

Unternehmen mit wenigen Projek-

ten sehen keinen Zusammenhang

zwischen Einsatz von PM und dem

wirtschaftlichen Unternehmenser-

folg

98 Elisabeth Schwarz und Timm Eichenberg

Kann der deut-

sche Mittelstand

agil? [SJ19]

Quantitative

Studie mit On-

line-Frageboden

Anschließend

qualitative Ex-

perteninterviews

271 Führungskräfte mit

Gesamt- oder Teilunter-

nehmens-verantwortung

in mittelständischen

Unternehmen verschie-

dener Branchen und

Größen

68,3 % der Befragten haben Agilität

in der Unternehmensstrategie veran-

kert und verfolgen Ziel, eine agile

Organisation zu sein.

16 % sehen keine überzeugenden

Vorteile in agilem Handeln, 15 %

ist Agilität unbekannt.

Anwendung agiler Tools und Me-

thoden wird von den Unternehmen

als am wenigsten relevant angese-

hen.

„Agile Trans-

formation –

Doing Agile ver-

sus Being Agile“

[Zi20]

Quantitative

Studie wird an-

genommen

Telefonische

und digitale Da-

tenerhebung

208 große mittel-ständi-

sche Unternehmen und

Konzerne

breiten Branchenquer-

schnitt; mehrheitlich In-

dustriesektor

49 % der befragten Un-

ternehmen erwirtschaf-

tete 2019 über 1 Milli-

arde Euro.

Interviewpartner sind

Digital- und IT-Mana-

ger. 64 % sind CIO,

CTO und CDO.

10 % der Unternehmen arbeiten mit

agilen Methoden

32 % der Führungskräfte verfügen

über agile Methodenkompetenz

Schwächen im agilen Mindset; Agi-

lität nicht in Kultur und Führungs-

stil verankert

31 % der Top-Manager treiben

agile Transformation voran, tun sich

schwer, Mitarbeitenden „Gestal-

tungsfreiräume, Selbstbestimmung

und -organisation“ einzuräumen

und eigene Entscheidungsbefug-

nisse zu reduzieren.

im Top-Management und beim Ein-

satz agiler Frameworks zeigt sich

„Diskrepanz zwischen ,agil sein

wollen‘ und ,agil sein‘

Status Quo

(Scaled) Agile –

4. Auflage

[Ho20]

Quantitative

Studie: Online-

Umfrage mit

Fragebogen in

englischer und

deutscher Spra-

che

Zeitraum von 24

09 2019 bis 29

11 2019

642 Teilnehmende aus

26 Ländern

Verbreitet über ver-

schiedene Newsletter,

Blogs, Webseiten, Pub-

likationen und Tweets

Keine Angaben zu Teil-

nehmenden

agile Methoden mehrheitlich selek-

tiv und in Mischform mit klassi-

schen PM-Methoden angewendet

85 % sehen durch Einsatz agiler

Methoden eine Verbesserung der

Projektergebnisse und gestiegene

Effizienz eingetreten

wichtigste Gründe für Einsatz agiler

Methoden Risiko-Reduktion, Pro-

dukteinführungszeiten und Qualität

größte Herausforderungen für den

erfolgreichen Einsatz agiler Metho-

den sind „Interne Prozesse“ und

„Top-Management“

HybridAgil

[KCB22]

Quantitative On-

line-Studie

HybridAgil be-

inhaltet eine

Reihe von Stu-

dien, die zwi-

schen

01.01.2019 bis

31.12.2021

durchgeführt

wurden

655 Unternehmen aus

16 Ländern

Stichprobe: 40 % kleine

KMU, 24 % mittlere

und 36 % große Unter-

nehmen

Geschäftsführer und

Führungskräfte aus der

Produktion im verarbei-

tenden Gewerbe

In nur 45 % der deutschen Unter-

nehmen spielt Agilität und Einsatz

agiler Methoden eine Rolle

Im internationalen Vergleich damit

Schlusslicht

Minderheit der Unternehmen nut-

zen agile Methoden zur Weiterent-

wicklung von Produkten, Service-

leistungen und Geschäftsmodellen

China (88 %), Indien (82 %) und

Mexiko (86 %) arbeiten häufiger

agil

Einsatz agiler und offener Entwick-

lungsmethoden wirkt sich signifi-

kant positiv auf den Umsatzanteil

Einsatz agiler Projektmanagementmethoden in KMU 99

mit digitalen Services und Ge-

schäftsmodellen aus

Agile Entwick-

lung physischer

Produkte

[Mi22]

Quantitative On-

line-Studie mit

41 geschlosse-

nen Fragen und

einer offenen

Frage von 01-

03/2022

Likert-Skala

wird angewen-

det

Studienreihe

wird jährlich

seit 2017 mit

verschiedenen

Schwerpunkten

durchgeführt

Stichprobengröße 128

Teilnehmende aus der

DACH-Region; 43 %

Projekt- und Gruppen-

leiter, 9 % Geschäfts-

führung, 15 % Agile

Coaches

Verbreitung: persönli-

che Kontakte, Newslet-

ter des VDI und soziale

Medien

Branchen: 25 % Ma-

schinen & Anlagenbau,

21 % Fahrzeug- & Ver-

kehrstechnik

17 % KMU

Bei 22 % der Teilnehmenden ist

agile Produktentwicklung das domi-

nante Vorgehensmodell; 62 % der

Anwendung bei Neuentwicklungen

Klassische Projektrollen sind etab-

liert; agiles Rollenverständnis hat

sich noch nicht durchgesetzt

Nur 30 % wenden agile Vorgehens-

modelle ohne (2%) oder mit gerin-

gen Adaptionen an

Konflikte bei Einführung von agi-

lem PM: Machtverlust der Füh-

rungsebene, Verlust klassischer

Karrierepfade, Führung durch Ziele;

Entscheidungsgewalt

Weiche Faktoren werden verbessert

Selbstorganisation beeinflusst Pro-

jekterfolg

Tabelle 4: Übersicht über empirische Studien zum agilen Projektmanagement

100

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 101

Von Anfang an mit KI: Lösungsskizzen mit intelligenten

Komponenten gestalten

Kokulan Thanabalan1 und Axel Kalenborn2

Abstract: Künstliche Intelligenz (KI), insbesondere generative Modelle wie Large Language Mo-

dels (LLMs), gewinnt zunehmend an Bedeutung in der Softwareentwicklung. Während der Einsatz

in der Entwicklungs- und Managementphase bereits weit verbreitet ist, bleibt das Potenzial von KI

in frühen Projektphasen, wie Angebotserstellung und Lösungskonzeption, oft ungenutzt. Dieses Pa-

per zeigt, wie KI bereits in der Vorvertragsphase systematisch integriert werden kann, um Innovati-

onskraft, Effizienz und Zukunftsfähigkeit von Softwarelösungen zu steigern. Anhand typischer Ein-

satzfelder wie Mustererkennung, Klassifikation, Tracking und Textgenerierung sowie konkreter

Praxisbeispiele wird gezeigt, wie KI gewinnbringend in technische Skizzen eingebettet werden

kann. Ziel ist es, Projektverantwortliche dafür zu sensibilisieren, KI nicht nur als Hilfsmittel für ihre

eigene Arbeit zu verwenden, sondern als zentralen Bestandteil moderner Lösungsarchitekturen zu

verstehen und strategisch einzusetzen.

Keywords: Large Language Model, Angebote, KI-Potentiale, Künstliche Intelligenz

1 Einleitung

Künstliche Intelligenz (KI) hat sich in den letzten Jahren zu einer Schlüsseltechnologie in

der Softwareentwicklung entwickelt. Insbesondere generative KI und maschinelles Ler-

nen werden zunehmend in Bereichen wie automatisierte Codegenerierung, Testfallablei-

tung, Anforderungsanalyse und Projektmanagement eingesetzt [Br20]. Eine zentrale tech-

nologische Grundlage vieler moderner Anwendungen bildet die Klasse der Large Langu-

age Models (LLMs). Diese Sprachmodelle basieren auf neuronalen Netzen mit Milliarden

von Parametern und werden auf umfangreichen Mengen Textdaten trainiert. Ermöglicht

wurde diese Entwicklung durch Fortschritte im Deep Learning, die Verfügbarkeit großer

Rechenressourcen und riesige Trainingsdatensätze. LLMs sind in der Lage, Sprache auf

hohem Niveau zu verstehen und zu generieren [Sh23]. Tools wie ChatGPT, Gemini,

GitHub-Copilot oder KI-gestützte Assistenzsysteme helfen Entwicklerinnen und Entwick-

lern sowie Projektverantwortlichen bereits heute dabei, komplexe Aufgaben schneller, ef-

fizienter und oft auch kreativer zu bewältigen.

Auch beim Management der Software-Projekte nimmt die Nutzung von KI-Technologien

stetig zu. Hier finden sich in allen Phasen hilfreiche Tools, die z.B. bei der Zusammen-

stellung von Arbeitspaketen, der Risikobewertung oder der Aufwandsschätzung helfen

[La20], [Lo24].

1 Universität Trier, Wirtschaftsinformatik, Behringstraße 21, 54286 Trier, thanabalan@uni-trier.de

2 Universität Trier, Wirtschaftsinformatik, Behringstraße 21, 54286 Trier, axel.kalenborn@uni-trier.de

102 Kokulan Thanabalan und Axel Kalenborn

Während somit der praktische Einsatz von KI in der Entwicklungs- und Managementphase

stetig zunimmt, zeigen sich Defizite in zwei anderen zentralen Phasen der Softwareent-

wicklung: Der Vorvertragsphase, in der die Angebote für die umzusetzende Software er-

stellt wird, sowie bei der Erstellung von Lösungsskizzen und damit der Grundlage für die

spätere Realisierung der Projekte [Zh23b]. Diese frühen konzeptionellen Entwürfe dienen

als verbindende Brücke zwischen den Anforderungen und der Implementierung. Sie legen

die grobe Architektur fest, beinhalten erste Lösungsskizzen und legen bereits die zu ver-

wendenden Technologien fest.

Aktuell wird in Angeboten und Lösungsskizzen jedoch häufig noch traditionell gedacht:

Systeme werden algorithmisch entworfen, KI-Potenziale bleiben unberücksichtigt. Die

Möglichkeit, KI als integralen Bestandteil einer Lösung – etwa zur Klassifikation, auto-

matisierten Strukturierung, Sprachverarbeitung oder Entscheidungsunterstützung – bereits

im Architekturentwurf mitzudenken, wird noch nicht ausreichen ausgeschöpft. Dies führt

dazu, dass wertvolle Chancen zur Effizienzsteigerung, Nutzerzentrierung und Differen-

zierung ungenutzt bleiben oder erst in späteren Projektphasen aufwendig nachgerüstet

werden. Zudem erhöht eine frühe Berücksichtigung von KI-Potentialen die Wettbewerbs-

fähigkeit sowie die Zukunftssicherheit, da sich viele Probleme, die nur sehr aufwändig mit

Algorithmen gelöst werden können, mit KI deutlich einfacher und wirtschaftlicher lösen

lassen.

Ziel dieses Papers ist es daher, Vertriebsmitarbeiter, Projektmanagerinnen und -manager

sowie Softwareingenieure dafür zu sensibilisieren, die Potenziale von KI bereits in der

Phase der Lösungskonzeption systematisch zu erkennen und zu integrieren. Dazu werden

typische Einsatzmuster von KI skizziert, die sich in Lösungsskizzen abbilden lassen, und

praxisnahe Empfehlungen gegeben, wie intelligente Komponenten sinnvoll und verant-

wortungsvoll in technische Entwürfe eingebunden werden können.

Methodisch folgt dieses Paper dem Design-Science-Ansatz [He04], [VK07]. Das Ziel des

Ansatzes besteht darin, innovative Artefakte (z. B. Modelle, Methoden, Frameworks oder

Software) zu gestalten und zu evaluieren, um reale Probleme zu lösen und gleichzeitig

theoretisches Wissen zu erweitern zu können. Als empirischer Kontext für dieses Paper

wird eine kaufmännische Software verwendet, die in verschiedenen Unternehmen und der

öffentlichen Hand eingesetzt wird, außerdem werden Artefakte aus Individualprojekten

verwendet.

2 Von der Anforderung zur (KI-)Lösung

Angebote und Lösungsskizzen sind zentrale Kommunikations- und Planungsinstrumente

in den frühen Phasen von Softwareprojekten. Sie dienen dazu, auf anschauliche Weise zu

vermitteln, wie eine Anwendung funktioniert und welche Anforderungen sie erfüllen soll

und wie hoch der Aufwand für die Umsetzung der Anwendung sein wird. Im Unterschied

zu formalen Architekturmodellen stehen in der Praxis häufig visuelle Mock-Ups, Prozess-

beschreibungen, Use Cases und erläuternde Texte im Mittelpunkt. Sie helfen Teams dabei,

fachliche Anforderungen zu strukturieren, Lösungsansätze zu visualisieren und ein ge-

meinsames Verständnis über die spätere Systemfunktionalität zu entwickeln. [Ka14]

Das Team-Quality-Level als Basis für KI-generierte Handlungsempfehlungen 103

Wie bereits ausgeführt, beginnt die inhaltliche Auseinandersetzung mit einer Lösung in

nahezu allen Projekten nicht erst nach Projektstart, sondern in der Vorvertragsphase. Im

Rahmen der Angebotserstellung. Auftraggeber erwarten bei einem Angebot nicht nur eine

Kostenschätzung, sondern auch eine erste Vorstellung davon, wie ein Problem gelöst wer-

den kann. Angebote enthalten deshalb meist bereits vorläufige Lösungsskizzen, in denen

zentrale Systemideen, technologische Ansätze oder beispielhafte Abläufe beschrieben und

visualisiert werden.

Das sich in der Vorvertragsphase potentielle Auftragnehmer im Wettbewerb miteinander

befinden, ist der Innovationsgrad sowie die Wirtschaftlichkeit eines Angebots entschei-

dend für den Zuschlag. In beiden Bereichen sollte das Potential von KI genutzt werden,

um dem Wettbewerb möglichst einen Schritt voraus zu sein. Eine Lösungsskizze, die be-

reits intelligente Komponenten berücksichtigt, kann sich positiv auf die Wahrnehmung

von Innovationskraft und Zukunftsfähigkeit auswirken.

Die Skizzen entstehen typischerweise in interdisziplinären Workshops oder in enger Ab-

stimmung zwischen Fachbereich, Projektmanagement und Entwicklung. Ziel ist nicht die

vollständige Ausformulierung aller technischen Details, sondern eine verständliche, nach-

vollziehbare und grob-strukturierte Beschreibung der geplanten Lösung. Die Lösungs-

skizze bildet damit eine wichtige Brücke zwischen der Anforderungserhebung und der

späteren Umsetzung.

Gerade in dieser frühen Planungsphase bietet es jedoch entscheidende Vorteile, KI-ge-

stützte Funktionalitäten mitzudenken: Sie erweitern die Lösungsspielräume, eröffnen neue

Interaktionsformen und können langfristig die Nutzerzufriedenheit und Wartbarkeit der

Anwendung verbessern. Die Herausforderung besteht darin, diese Möglichkeiten frühzei-

tig zu erkennen und sinnvoll in die konzeptionellen Skizzen zu integrieren – sei es durch

gezielte Verweise auf KI-Komponenten, durch narrative Szenarien mit KI-Verhalten oder

durch die Formulierung offener Fragestellungen, die durch maschinelles Lernen adressiert

werden könnten.

3 Potentiale und Einsatzfelder von KI in Softwaresystemen

Künstliche Intelligenz bietet heute in modernen Softwaresystemen eine Vielzahl von Ein-

satzmöglichkeiten, die weit über klassische regelbasierte Logik hinausgehen. Besonders

wirksam zeigt sich KI in Bereichen, in denen große Datenmengen, unscharfe Informatio-

nen oder individuelle Nutzerkontexte verarbeitet werden müssen.

Grundlage der Auswahl ist eine systematische Analyse wissenschaftlicher Arbeiten, bei

der die Einsatzfelder generativer KI entlang funktionaler Zielsetzungen kategorisiert wur-

den. Die wissenschaftliche Einordnung folgt in Anlehnung an die Kategorisierung von

Zhao et al. (2020) und Sinjanka et al. (2023), die sechs übergeordnete Zielbereiche für den

Einsatz von LLMs identifizieren: Extraktion und Mustererkennung, Klassifikation, Tra-

cking und Modellierung, Textgenerierung [Zh20], [SIM23]. Abbildung 1 zeigt eine erste

Übersicht von denkbaren Aufgaben, die mit neuer KI-Technologie umgesetzt werden kön-

nen [PVB24]. In den folgenden Unterkapiteln werden die einzelnen Kategorien im Detail

besprochen.

104 Kokulan Thanabalan und Axel Kalenborn

Abbildung 1: Einsatzmöglichkeiten der KI, eigene Erstellung.

3.1 Extraktion und Mustererkennung

LLMs ermöglichen die automatisierte Verarbeitung unstrukturierter Datenquellen, etwa

Freitexten, PDFs oder E-Mails. Dabei werden relevante Informationen – etwa Ansprech-

partner, Kundennummern oder Bestellnummern – zuverlässig identifiziert und extrahiert

[Zh23a]. Diese Fähigkeit ist essenziell für Prozesse, bei denen strukturierte Daten aus un-

übersichtlichen oder heterogenen Formaten benötigt werden, beispielsweise in der Kun-

denkommunikation oder im Dokumentenmanagement.

Über die reine Informationsextraktion hinaus unterstützen KI-Modelle auch die Erken-

nung komplexer Muster in Daten. Sie liefern datenbasierte Empfehlungen und Bewertun-

gen, etwa in Form von Risikoeinschätzungen, Prognosen oder Anomalieerkennungen.

Diese Systeme treffen keine finalen Entscheidungen, sondern fungieren als intelligente

Entscheidungsunterstützung für menschliche Akteure oder zur Steuerung nachgelagerter

Prozesse [Fa23].

3.2 Klassifikation

Als Klassifikation wird die Fähigkeit bezeichnet, Texte oder Informationen automatisiert

zu bestimmten und in eine Ordnung zu bringen. Diese Funktion kommt etwa bei der Ver-

arbeitung von Kundenfeedback, bei der Risikobewertung oder der Zuordnung von Vor-

gängen zu Prozesspfaden zum Einsatz [PVB24]. In der automatischen Entscheidungsun-

terstützung können LLMs eingehende Anfragen oder Dokumente in definierte Kategorien

einordnen und so Bearbeitungswege oder Eskalationsstufen automatisch auswählen. Auch

in der Personalisierung wird Klassifikation genutzt, um Nutzerverhalten bestimmten

Gruppen zuzuordnen und Inhalte gezielt auszuspielen.

3.3 Tracking und Modellierung

LLMs unterstützen das kontinuierliche Erfassen und Analysieren von Informationen aus

internen und externen Datenströmen. Diese Fähigkeit – auch als Tracking bezeichnet –

ermöglicht die frühzeitige Erkennung von Veränderungen und Mustern in dynamischen

Umgebungen [WWS23]. Besonders in der Prozessüberwachung oder bei der Analyse von

Das Team-Quality-Level als Basis für KI-generierte Handlungsempfehlungen 105

Nutzerinteraktionen liefert Tracking wertvolle Einblicke: So lassen sich etwa Abweichun-

gen im Ablauf digitaler Geschäftsprozesse frühzeitig identifizieren oder Inhalte und Ab-

läufe personalisierter Softwaresysteme automatisiert an das Verhalten von Anwendern an-

passen. Tracking bildet damit eine zentrale Grundlage für intelligente, adaptive Systeme.

Ergänzend dazu kommt die Modellierung historischer Daten zum Einsatz. Hier erkennen

LLMs relevante Muster in vergangenen Entwicklungen, um daraus fundierte Prognosen

abzuleiten – etwa zu Nachfrageverläufen, Durchlaufzeiten oder finanziellen Kennzahlen

[Fa23]. Diese vorausschauenden Modelle ermöglichen datenbasierte Handlungsempfeh-

lungen, die sowohl für operative Entscheidungen als auch für strategische Planungen nutz-

bar sind. So leisten LLMs einen wichtigen Beitrag zur verbesserten Steuerung, Planung

und Risikoeinschätzung in einer Vielzahl von Anwendungsfeldern.

3.4 Textgenerierung

Textgenerierung bezeichnet die Fähigkeit von KI-Systemen, aus strukturierten oder un-

strukturierten Daten neue, kohärente Texte zu erstellen oder bestehende Inhalte in eine

andere Form zu überführen. Sie umfasst dabei verschiedene Anwendungsformen, die in

datengetriebenen Geschäftsprozessen vielfältige Mehrwerte schaffen.

Ein zentraler Anwendungsbereich ist die automatische Zusammenfassung. Dabei werden

längere Texte auf ihre wesentlichen Inhalte verdichtet und kompakt dargestellt. Dies un-

terstützt die schnelle Entscheidungsfindung, indem relevante Informationen gezielt extra-

hiert und verständlich aufbereitet werden. Typische Beispiele sind die automatisierte Zu-

sammenfassung von E-Mail-Verläufen oder die Reduktion komplexer Vertragsdokumente

auf zentrale Klauseln – etwa zur Effizienzsteigerung in juristischen Prüfprozessen

[Zh23a], [PVB24].

Ein weiterer wichtiger Anwendungsfall ist die automatische Übersetzung [Zh23a]. KI-

Modelle können Texte in Echtzeit in verschiedene Sprachen übertragen, wodurch interna-

tionale Kommunikation erleichtert und mehrsprachige Inhalte schneller zugänglich ge-

macht werden. Dies ist besonders relevant für global agierende Unternehmen, die Inhalte

für unterschiedliche Märkte bereitstellen müssen.

Auch die Code-Generierung gehört zur Textgenerierung. Hierbei werden aus natürlichen

Spracheingaben (z. B. „Schreibe eine Funktion zur Sortierung einer Liste“) direkt ausführ-

bare Programmcodes erstellt [Br20]. Diese Fähigkeit beschleunigt Entwicklungsprozesse

erheblich und unterstützt insbesondere weniger technisch versierte Nutzer dabei, program-

miernahe Aufgaben zu lösen.

4 Praktische Beispiele für die KI-Nutzung

Die zuvor beschriebenen Kategorien und Fähigkeiten Künstlicher Intelligenz, insbeson-

dere von LLMs, lassen sich gezielt auf typische Herausforderungen in der Unternehmen-

spraxis übertragen. Vor allem in datenintensiven Geschäftsprozessen entfalten generative

KI-Systeme ihr Potenzial durch Strukturierung unübersichtlicher Informationen, Automa-

tisierung repetitiver Aufgaben und intelligente Entscheidungsunterstützung.

106 Kokulan Thanabalan und Axel Kalenborn

Die im Folgenden dargestellten Praxisbeispiele basieren auf realen Anwendungen in ver-

schiedenen Domänen. Die gezeigten Einsatzformen sind produktiv im Einsatz und ver-

deutlichen die konkrete Wirksamkeit von LLMs in betrieblichen Abläufen. Sie wurden im

Rahmen interner Fallstudien und praxisnaher Analysen identifiziert, die den Einsatz ge-

nerativer KI in unterschiedlichen betrieblichen Kontexten systematisch untersucht haben.

Dazu werden im Folgenden drei konkrete Anwendungsszenarien vorgestellt: die Struktu-

rierung externer Datenquellen, die Unterstützung bei der Datenerfassung sowie die Kon-

trolle komplexer Geschäftsvorfälle. Diese Beispiele zeigen praxisnah, wie generative KI

in operativen Kontexten genutzt werden kann, um Effizienz, Genauigkeit und Skalierbar-

keit zu verbessern.

4.1 Strukturierung von externen Daten

Die Integration externer Datenquellen stellt Unternehmen häufig vor die Herausforderung,

Informationen aus unstrukturierten oder semi-strukturierten Formaten in die eigene Sys-

temlandschaft zu überführen. Besonders aufwendig ist dies, wenn relevante Daten bei-

spielsweise in PDFs, E-Mails oder anderen nicht-standardisierten Formaten vorliegen und

manuell aufbereitet werden müssen. Eine praktische Fallstudie konnte zeigen, dass LLMs

in der Lage sind, solche unstrukturierten Daten zu analysieren, relevante Inhalte zu extra-

hieren und sie in strukturierter Form, beispielsweise als Tabelle, aufzubereiten [Th23]. In

einem konkreten Anwendungsfall mussten Mitarbeitende regelmäßig Preislisten aus PDF-

Dokumenten manuell mit den im kaufmännischen System hinterlegten Produktinformati-

onen abgleichen und aktualisieren. Dieser Vorgang war nicht nur zeitintensiv, sondern

auch anfällig für Übertragungsfehler. In durchgeführten Experimenten sowie dem späte-

ren praktischen Einsatz zeigte sich, dass LLMs in der Lage sind, Produkte und zugehörige

Preise automatisiert aus den PDF-Tabellen zu extrahieren und korrekt in eine strukturierte

Datenform zu überführen. Damit wird nicht nur die Datenqualität erhöht, sondern auch

der Prozess der Datenintegration erheblich beschleunigt, was in dynamischen Märkten mit

häufig wechselnden Preisstrukturen einen entscheidenden Vorteil darstellt.

4.2 Unterstützung bei der Datenerfassung

Die manuelle Erfassung von Daten über Formulare zählt in vielen Unternehmen zu den

besonders zeitaufwändigen und fehleranfälligen Aufgaben. Prozesse wie das Anlegen

neuer Kunden oder Produkte erfordern häufig das Ausfüllen zahlreicher Formularfelder.

Diese Tätigkeit hält Mitarbeitende häufig von ihrem eigentlichen Tagesgeschäft ab. In der

Praxis werden die benötigten Informationen oft in unstrukturierter Form übermittelt, zum

Beispiel per E-Mail. Ein typisches Szenario besteht darin, dass ein Kunde seine Daten als

Fließtext an den Vertrieb sendet und eine Mitarbeiterin oder ein Mitarbeiter anschließend

die relevanten Informationen manuell in die vorgesehenen Felder eines Formulars über-

trägt.

Das Team-Quality-Level als Basis für KI-generierte Handlungsempfehlungen 107

Abbildung 2: Datenerfassung über KI, eigene Erstellung.

An dieser Stelle können LLMs wie GPT wirkungsvoll unterstützen. Wie eine weitere prak-

tische Fallstudie zeigt, sind moderne Sprachmodelle in der Lage, unstrukturierte Freitexte

zu analysieren, relevante Inhalte zu erkennen und diese automatisch den passenden Ein-

gabefeldern eines digitalen Formulars zuzuordnen [Kl24]. Die Nutzerinnen und Nutzer

müssen nicht mehr jedes Feld einzeln ausfüllen, sondern können den gesamten Textblock

übergeben. Das Modell übernimmt im Hintergrund die Strukturierung und Zuordnung der

Informationen. Dadurch sinkt nicht nur der Aufwand, sondern auch die Fehleranfälligkeit

wird verringert und die Datenerfassung deutlich beschleunigt.

Ergänzend wurde die Möglichkeit geschaffen, Formulare per Spracheingabe auszufüllen.

Dabei wandelt ein KI-System das gesprochene Wort in natürliche Sprache um und über-

trägt die erkannten Informationen direkt in die entsprechenden Formularfelder. Diese

Funktion erleichtert die Eingabe von Daten in Situationen, in denen die Nutzung einer

Tastatur nicht möglich oder nicht sinnvoll ist. Gleichzeitig wird die Barrierefreiheit ver-

bessert, da auch Menschen mit körperlichen Einschränkungen einfacher auf digitale For-

mulare zugreifen können.

4.3 Kontrolle komplexer Geschäftsvorfälle

Die Erstellung und Prüfung geschäftlicher Dokumente, wie etwa Rechnungen oder Ver-

träge, gehört zu den zentralen Aufgaben in nahezu jedem Unternehmen. Besonders bei

international tätigen Firmen ergeben sich dabei komplexe Anforderungen durch unter-

schiedliche gesetzliche Vorgaben und steuerliche Regelungen in den jeweiligen Ländern.

In vielen Unternehmen stellt insbesondere die korrekte Rechnungsstellung für ausländi-

sche Kunden eine Herausforderung dar. Denn Steuersätze, Pflichtangaben oder Wäh-

rungsangaben unterscheiden sich je nach Land. Dies erschwert die Bearbeitung, vor allem

für neue Mitarbeitende ohne fundierte Kenntnisse länderspezifischer Vorschriften.

Zur Qualitätssicherung wird in diesem Kontext ein LLM eingesetzt, das zur automatisier-

ten Prüfung von Rechnungen verwendet wird. Das Modell analysiert den Inhalt fertig er-

stellter Rechnungen, erkennt potenzielle Abweichungen wie fehlerhafte Steuersätze oder

unvollständige Pflichtangaben und schlägt gegebenenfalls notwendige Korrekturen vor.

Dabei berücksichtigt es gespeicherte Regeln, typische Muster und länderspezifische Kon-

texte. Der Einsatz des LLMs dient somit nicht nur der Fehlervermeidung, sondern auch

der spürbaren Entlastung des Personals bei grenzüberschreitenden Geschäftsvorfällen.

Abbildung 3 veranschaulicht eine beispielhafte Prüfung.

108 Kokulan Thanabalan und Axel Kalenborn

Abbildung 3: Kontrolle von Geschäftsvorfällen über KI, eigene Erstellung.

Ein weiterer Vorteil liegt in der Kostenersparnis. Die Nutzung eines leistungsstarken Mo-

dells wie GPT-4.1 von OpenAI verursacht vergleichsweise geringe Kosten. Aktuell liegen

die Preise bei etwa zwei US-Dollar pro einer Million Eingabetoken und acht US-Dollar

pro einer Million Ausgabetoken [Op25a]. Ein Dokument mit ungefähr 75 Wörtern ent-

spricht im Schnitt etwa 100 Token [Op25b]. Angenommen ein Dokument umfasst 300

Token und das Modell generiert eine Ausgabe mit 1000 Token, so lassen sich für 2 US-

Dollar ca. 230 Dokumente automatisiert verarbeiten.

Unternehmen profitieren somit nicht nur von der Automatisierung, sondern auch von sig-

nifikanten Kostenvorteilen im Vergleich zu einer manuellen Prüfung durch Fachkräfte.

Darüber hinaus spart man wertvolle Zeit von Expertinnen und Experten, etwa Steuerbera-

terinnen und Steuerberatern, die sich dadurch auf höherwertige Tätigkeiten konzentrieren

können, anstatt wiederholt formale Korrekturen vornehmen zu müssen.

5 Grenzen der KI-Nutzung

Wie die vorangegangenen Ausführungen gezeigt haben, bieten LLMs viele Vorteile in

unternehmensnahen Anwendungsszenarien. Trotz dieser Potenziale sollten Fachverant-

wortliche frühzeitig zentrale Herausforderungen erkennen und adressieren. Besonders

hervorzuheben sind dabei drei zentrale Risikobereiche: erstens operationale Herausforde-

rungen, zweitens soziale und rechtliche Risiken und drittens technologische Abhängigkei-

ten [PVB24].

Operationale Herausforderungen

Der produktive Einsatz generativer KI-Systeme ist mit technischen Einschränkungen ver-

bunden, die sich direkt auf die betrieblichen Abläufe auswirken können. Eine zentrale

Herausforderung stellt die Nachvollziehbarkeit und Erklärbarkeit der Entscheidungen dar,

die durch das Modell getroffen werden [PVB24]. So kann es beispielsweise vorkommen,

dass ein LLM die Daten aus PDF-Dokumenten fehlerhaft oder nicht nachvollziehbar

strukturiert oder Geschäftsvorfälle fehlerhaft untersucht. Die Ursache für solche Fehler ist

oft nicht ersichtlich, was die Validierung der Ergebnisse erschwert. Dies ist besonders

kritisch in sensiblen Anwendungsfeldern wie der automatisierten Prüfung von Rechnun-

gen.

Das Team-Quality-Level als Basis für KI-generierte Handlungsempfehlungen 109

Darüber hinaus spielen wirtschaftliche Faktoren eine wichtige Rolle. Die Verarbeitung

großer Datenmengen sowie häufige Anfragen an cloudbasierte LLM-Dienste können hohe

Betriebskosten verursachen. Ein weiterer wichtiger Aspekt ist die Transparenz innerhalb

komplexer IT-Systeme. Wenn etwa die Prüfung von Rechnungen automatisiert im Hinter-

grund erfolgt, sollten geeignete Maßnahmen zur Protokollierung, Überwachung und Ein-

bindung von Nutzerfeedback vorgesehen werden. Nur so kann die Funktionsweise des

Systems nachvollziehbar und kontrollierbar gestaltet werden.

Soziale und rechtliche Risiken

Ein bedeutendes Risiko besteht in der Generierung sogenannter Halluzinationen. Dabei

produziert das Modell zwar sprachlich plausible, aber inhaltlich falsche Informationen

[Mi24]. So kann es beispielsweise vorkommen, dass fiktive Produktkategorien hinzuge-

fügt oder falsche Steuersätze angegeben werden. In automatisierten Prozessen kann dies

zu Desinformation führen, insbesondere dann, wenn keine nachgelagerte Validierung vor-

gesehen ist.

Darüber hinaus ist der Schutz personenbezogener Daten und die Einhaltung rechtlicher

Vorgaben von zentraler Bedeutung. Wenn zum Beispiel bei der Kundenanlage Freitexte

verarbeitet werden, muss sichergestellt sein, dass sensible Informationen weder dauerhaft

gespeichert noch unrechtmäßig weitergegeben werden. In diesem Zusammenhang greifen

gesetzliche Regelungen wie der künftige AI Act der Europäischen Union [LTD24].

Eine mögliche Lösung besteht darin, LLMs lokal zu betreiben. Durch die interne Verar-

beitung der Daten innerhalb der eigenen Infrastruktur kann verhindert werden, dass sen-

sible Inhalte das Unternehmen verlassen. Auf diese Weise lassen sich Datenschutzanfor-

derungen deutlich besser kontrollieren und erfüllen.

Technologische Risiken und Abhängigkeiten

Der Einsatz externer KI-Dienste führt zwangsläufig zu technologischen Abhängigkeiten

[PVB24]. Dies gilt insbesondere dann, wenn LLMs über Programmierschnittstellen von

proprietären Anbietern wie OpenAI oder Google in die Systemlandschaft eingebunden

werden. Änderungen an den Modellen, an den Lizenzbedingungen oder an technischen

Zugriffsbeschränkungen können unmittelbare Auswirkungen auf produktive Anwendun-

gen haben. Dieses Risiko ist besonders relevant, wenn geschäftskritische Prozesse auf dem

kontinuierlichen Einsatz solcher Dienste basieren oder wenn das Geschäftsmodell selbst

stark von KI-Funktionalitäten abhängt.

Hinzu kommt das Risiko von Systemausfällen oder temporären Inkompatibilitäten. Diese

können dazu führen, dass automatisierte Abläufe unterbrochen oder verzögert werden.

Ohne passende Ausweichstrategien können selbst einfache Prozessschritte ins Stocken ge-

raten.

Um solchen Szenarien vorzubeugen, sollten Softwarearchitekturen konsequent auf Aus-

fallsicherheit ausgelegt sein. Dazu gehören funktionale Redundanzen, ein kontinuierliches

Monitoring sowie robuste Mechanismen zur Fehlerbehandlung. Nur so lässt sich die lang-

fristige Stabilität und Verfügbarkeit von KI-gestützten Systemen im Unternehmenskon-

text gewährleisten.

110 Kokulan Thanabalan und Axel Kalenborn

6 Fazit

Wir fangen gerade erst an, die Potentiale von KI in Business Anwendungen zu verstehen.

Aktuell werden KI-Funktionen meist noch über die Chat Werkzeuge der Anbieter, wie

ChatGPT oder Gemini genutzt. Die nahtlose Integration in Business Software beginnt ge-

rade, wie Microsoft in den Office Anwendungen über den Copilot zeigt.

Wir haben in diesem Paper die Potentiale und Einsatzfelder von KI bei der Softwareumset-

zung beleuchtet. Wenn mit der Konzeption einer Software begonnen wird, sollten diese

Potentiale berücksichtigt werden und die Software einfließen. Dazu sollten die umzuset-

zenden Funktionen mit den Einsatzbereichen der KI abgeglichen werden, um diese ge-

winnbringend nutzen zu können. Wo klassische Algorithmik, komplex und teuer ist, kann

die KI neue Möglichkeiten bieten. Wenn die Arbeit der Nutzer durch KI unterstützt und

vereinfacht werden kann, wird die Zufriedenheit der Nutzer steigen. Wenn durch die KI

weniger Fehler gemacht werden, dient das nicht nur der Einsparung von Kosten, sondern

erspart unnötige und ermüdende Kontrollen.

Bei unseren eigenen Arbeiten hat sich gezeigt, dass Probleme, die wir in der Vergangen-

heit als nicht lösbar im Rahmen kleiner und mittlerer Budgets eingeordnet haben, mit KI

so einfach umzusetzen waren, dass wir selbst über die Leistungsfähigkeit erstaunt waren.

Wir diskutieren daher zu Beginn jedes Projekts die Einsatzmöglichkeiten der KI für die

Umsetzung komplexer Funktionen und lassen dies in die Konzepte einfließen.

Auch der zur “Verhinderung” von KI-Lösungen immer wieder angeführte Datenschutz,

ist heute aus unserer Sicht kein Problem mehr, da sich LLMs sehr kosteneffizient und

trotzdem leistungsstark auf eigenen oder gemieteten Servern (Cloud-AI) oder auch lokal

(On-Device-AI) ausführen lassen.

Literaturverzeichnis

[Br20] Brown, T. & Mann, B. & Ryder, N. & Subbiah, M. & Kaplan, J. & Dhariwal, P. &

Neelakantan, A. & Shyam, P. & Sastry, G. & Askell, A. & Agarwal, S. & Herbert-Voss,

A. & Krueger, G. & Henighan, T. & Child, R. & Ramesh, A. & Ziegler, D. & Wu, J. &

Winter, C. & Amodei, D.: Language Models are Few-Shot Learners. In Proceedings of

the 34th International Conference on Neural Information Processing Systems (NIPS

'20). Curran Associates Inc., Red Hook, NY, USA, Article 159, 1877–1901, 2020.

[Fa21] Faßold, T.-J.: Requirements Engineering and Domain Knowledge. Requirements Engi-

neering Magazine, 2021.

[Fa23] Fatouros, G. & Soldatos, J. & Kouroumali, K. & Makridis, G. & Kyriazis, D.: Trans-

forming sentiment analysis in the financial domain with ChatGPT. Machine Learning

with Applications. 14, 2023.

[Gi23] Giray, L.: Prompt Engineering with ChatGPT: A Guide for Academic Writers. Ann Bi-

omed Eng, S. 2629-2633, 2023. Verfügbar unter: http://dx.doi.org/10.1007/s10439-023-

03272-4

[He04] Hevner, A. R. & March, S. T., & Park, J. & Ram, S.: Design science in information

systems research. MIS Quarterly, 28(1), 75–105, 2004.

Das Team-Quality-Level als Basis für KI-generierte Handlungsempfehlungen 111

[Ka14] Kalenborn, A.: Angebotserstellung und Planung von Internet-Projekten: die werkzeug-

basierte "Modeling by Example"-Methode, Springer Vieweg, 2014.

[Kl24] Klose, N.: Unterstützung bei der Eingabe und Validierung von Daten in Webanwen-

dungen mit Hilfe von KI-Tools, Masterarbeit, Universität Trier, 2024.

[La20] Lamsweerde, A.: Requirements Engineering in the Year 00: A Research Perspective. In

Proceedings of the 22nd international conference on Software engineering (ICSE '00).

Association for Computing Machinery, New York, NY, USA, 5–19, 2000.

[LTD24] Lee, D. & Todorova , C. & Dehghani , A.: Ethical Risks and Future Direction in Building

Trust for Large Language Models Application under the EU AI Act. In Proceedings of

the 2024 Conference on Human Centred Artificial Intelligence - Education and Practice

(HCAIep '24). Association for Computing Machinery, New York, NY, USA, S. 41–46,

2024.

[Lo24] Lo, D.: Requirements Engineering for Trustworthy Human-AI Synergy in Software En-

gineering 2.0. IEEE 32nd International Requirements Engineering Conference (RE),

Reykjavik, Iceland, 2024, pp. 3-4, 2024.

[Mi24] Minaee, S. & Mikolov, T. & Nikzad, N. & Chenaghlu, M.A. & Socher, R. & Amatriain,

X. & Gao, J.: Large Language Models: A Survey. ArXiv, abs/2402.06196, 2024.

[Op25a] OPENAI: Tokenizer: Learn about language model tokenization, Verfügbar unter:

https://platform.openai.com/tokenizer, abgerufen am 29. Juni 2025, 2025.

[Op25b] OPENAI: API-Preisgestaltung, Verfügbar unter: https://openai.com/de-DE/api/pricing,

abgerufen am 29. Juni 2025, 2025.

[Op25c] OPENAI: Best Practices for Prompt Engineering with the OpenAI API. Verfügbar unter:

https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-

with-the-openai-api, abgerufen am 28. Juni 2025, 2025.

[PVB24] Pessanha, G. & Vieira, A. & Brandão, W.: Large Language Models (LLMs): A system-

atic study in Administration and Business. In RAM, Rev. Adm. Mackenzie. 2024. Vol.

25, 2024.

[Ra24] Raiaan, M. & Mukta, S. & Fatema, K. & Fahad, N. & Sakib, S. & Mim, J. & Ahmad, J.

& Ali, M. & Azam, S.: A Review on Large Language Models: Architectures, Applica-

tions, Taxonomies, Open Issues and Challenges. In: IEEE Access. 2024 ; Vol. 12. S.

26839-26874, 2024.

[Sh23] Shen, Y. & Heacock, L. & Elias, J. & Hentel, K. & Reig, B. & Shih, G. & Moy, L.:

ChatGPT and Other Large Language Models Are Double-edged Swords. In Radiology.

307, 2023.

[SIM23] Sinjanka, Y. & Ibrahim, U. & Malate, F..: Text Analytics and Natural Language Pro-

cessing for Business Insights: A Comprehensive Review. International Journal for Re-

search in Applied Science and Engineering Technology, S. 1626 – 1653, 2023.

[SN05] Sneed, H. M.: Softwareprojektkalkulation, praxiserprobte Methoden der Aufwands-

schätzung für verschiedene Projektarten, Budapest, 2005.

[SO11] Sommerville, I.: Software Engineering, 9/E. Pearson Education India, 2011.

112 Kokulan Thanabalan und Axel Kalenborn

[Th23] Thanabalan, K.: Information Extraction from PDF Documents: A Practical Approach

with ChatGPT, Masterarbeit, Universität Trier, 2023.

[VK07] Vaishnavi, V. K. & Kuechler, W.: Design Science Research Methods and Patterns: In-

novating Information and Communication Technology, 2007.

[WWS23] Weingart, P. & Wambsgans, T. & Soellner, M.: A taxonomy for deriving business in-

sights from user-generated content. In ECIS 2023 Research Papers. 401, 2023.

[Zh20] Zhao, L. & Alhoshan, W. & Ferrari, A. & Letsholo, K. & Ajagbe, M. & Chioasca, E. &

Batista-Navarro, R.: Natural Language Processing (NLP) for Requirements Engineer-

ing: A Systematic Mapping Study. In: ACM Computing Surveys, Vol. 54, No. 3, 2020.

[Zh23a] Zhao, W. & Zhou, K. & Junyi, L. & Tianyi, T. & Wang, X. & Hou, Y. & Min, Y. &

Zhang, B. & Zhang, J. & Dong, Z. & Du, Y. & Yang, C. & Chen, Y. & Chen, Z. &

Jiang, J. & Ren, R. & Li, Y. & Tang, X. & Liu, Z. & Wen, J.: A Survey of Large Lan-

guage Models. arXiv.Org, abs/2303.18223, 2023.

[Zh23b] Zhang, Q. & Fang, C. & Xie, Y. & Zhang, Y. & Yang, Y. & Sun, W. & Yu, S. & Chen,

Z.: A Survey on Large Language Models for Software Engineering. CoRR

abs/2312.15223, 2023.

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 113

Wer führt die KI – und wie? Oder führt die KI uns?

Jan Wehinger1

Abstract:

Die fortschreitende Einführung Künstlicher Intelligenz (KI) in der Arbeitswelt stellt etab-

lierte Führungsprinzipien vor grundlegende Herausforderungen. Dieser Beitrag untersucht

die Auswirkungen von KI auf Führungsmodelle im Kontext von New Work 2.0 einer Ar-

beitswelt, die durch Digitalisierung, agile Methoden und hybride Zusammenarbeit geprägt

ist. Die zentrale Frage lautet: Wer führt die KI – und wie? Ausgehend von einer Analyse

der Grenzen klassischer Führungstheorien in Bezug auf KI werden drei neue Führungs-

modelle vorgestellt: (1) das Supervisory Leadership Model, bei dem der Mensch die KI

überwacht und steuert, (2) das Collaborative Leadership Model, das eine enge Zusam-

menarbeit zwischen Mensch und KI auf Augenhöhe vorsieht, und (3) das AI-Led Lea-

dership Model, in dem KI-Systeme selbst Führungsaufgaben übernehmen. Zur Unter-

mauerung dieser Modelle werden relevante wissenschaftliche Theorien herangezogen,

darunter die Supervisory Control Theory, das Konzept Joint Cognitive Systems sowie Er-

kenntnisse zum Algorithmic Management. Im weiteren Verlauf beschreibt der Beitrag neu

entstehende Rollen (z. B. AI Governance Officer und Human-KI-Integrator) und die er-

forderlichen Kompetenzen für Führungskräfte in einer KI-durchdrungenen Arbeitswelt.

Abschließend werden ethische sowie organisationale Implikationen hinsichtlich Entschei-

dungsverantwortung und Governance-Strukturen diskutiert und praxisorientierte Hand-

lungsempfehlungen für Unternehmen formuliert.

Keywords:

Künstliche Intelligenz; Führung; New Work; Führungsmodelle; Algorithmisches Ma-

nagement; Mensch-Maschine-Kollaboration; Ethik; Governance

1 Einleitung

Die rasant fortschreitende Entwicklung von KI-Technologien und ihre zunehmende In-

tegration in Geschäftsprozesse verändern grundlegend, wie Arbeit organisiert und geführt

wird. Insbesondere im Kontext von New Work 2.0, einer Phase des tiefgreifenden Wandels

der Arbeitswelt, werden traditionelle Vorstellungen von Führung auf die Probe gestellt.

1MHP, jan@wehinger.de

114 Jan Wehinger

KI-basierte Systeme übernehmen heute bereits Aufgaben in Entscheidungsfindung, Per-

sonalmanagement und Teamkoordination, die einst ausschließlich menschlichen Füh-

rungskräften vorbehalten waren. Dadurch verschwimmen die Grenzen zwischen mensch-

lichen Akteuren und technischen Agenten im Führungsgeschehen. Klassische Definitio-

nen von Führung als sozialer Einflussprozess eines Menschen auf andere Menschen

[Yukl12] greifen zu kurz, wenn autonome Software-Agenten zu wesentlichen Teammit-

gliedern oder gar Vorgesetzten werden.

Vor diesem Hintergrund stellt sich die Frage nach der künftigen Rollenverteilung zwi-

schen Mensch und KI in Führungsprozessen. Wer führt die KI – und wie? Diese Leit-

frage adressiert sowohl die Führung von KI (durch den Menschen) als auch die Führung

durch KI (über den Menschen). Bisherige Ansätze des Führungsmanagements müssen da-

hingehend überprüft werden, ob und wie sie auf hybrider Mensch-KI-Zusammenarbeit

anwendbar sind. In diesem Beitrag werden zunächst die Grenzen klassischer Führungs-

theorien im KI-Zeitalter aufgezeigt (Kap. 2). Darauf aufbauend werden drei neue Füh-

rungsmodelle entwickelt (Kap. 3). Diese Modelle werden mit einschlägigen Theorien aus

der Literatur verknüpft, um ihre wissenschaftliche Fundierung zu untermauern (Kap. 4).

Anschließend werden die nötigen neuen organisatorischen Rollen und Kompetenzen für

Führung im KI-Kontext erörtert (Kap. 5). Kapitel 6 diskutiert die ethischen und organisa-

tionalen Implikationen der Einbindung von KI in Führung. Abschließend gibt Kapitel 7

konkrete Handlungsempfehlungen für Unternehmen und fasst die Ergebnisse zusammen

Kapitel 8 Fazit.

2 Grenzen klassischer Führungstheorien im KI-Kontext

Klassische Führungstheorien haben unser Verständnis von effektiver Führung über Jahr-

zehnte geprägt. Doch viele dieser Theorien setzen implizit voraus, dass Führung aus-

schließlich in menschlichen Hierarchien stattfindet. Im Angesicht von KI-basierten Akt-

euren stoßen diese Ansätze an Grenzen. Im Folgenden werden exemplarisch drei einfluss-

reiche Führungsansätze und ihre Limitierungen im Umgang mit KI dargestellt:

• Transformationale Führung: Dieses Konzept [Bass94] betont die Fähigkeit

von Führungspersonen, durch Vision, Inspiration und individuelle Wertschät-

zung einen Wandel bei Mitarbeitern herbeizuführen. Eine Herausforderung im

KI-Kontext besteht darin, dass KI-Systeme keine menschlichen Emotionen oder

intrinsische Motivation besitzen. Ein transformationeller Führer kann zwar

menschliche Teammitglieder inspirieren, aber eine KI als „Geführter“ wird von

Vision und Charisma nicht beeinflusst. Umgekehrt stellt sich die Frage, ob KI-

Systeme jemals zu authentischer Inspiration oder Charisma fähig wären, um

Menschen zu transformieren, derzeit erscheint dies zweifelhaft.

• Situatives Leadership: Das situative Führungsmodell nach Hersey und

Blanchard [Hersey69] fordert von Führungskräften, ihren Führungsstil dem Rei-

fegrad der Mitarbeiter anzupassen (Direktivität vs. Unterstützung). Im Umgang

mit KI stößt dieses Prinzip auf konzeptionelle Probleme: Eine KI als Mitarbeiter

kennt weder Reifegrad noch Lernkurven im menschlichen Sinne, sie verfügt über

Wer führt die KI – und wie? Oder führt die KI uns? 115

spezifische Leistungsfähigkeiten, aber keine Motivation oder Persönlichkeits-

merkmale. Die Führungslogik „High Task/Low Relationship“ vs. „Low

Task/High Relationship“ lässt sich auf eine KI nicht übertragen, da Beziehungs-

orientierung gegenüber einer Maschine ins Leere läuft. Ebenso wenig kann eine

KI als Führungskraft situativ auf menschliche Empfindungen wie Angst oder Un-

sicherheit reagieren, wenn sie nicht entsprechend programmiert wurde.

• Servant Leadership: Der dienende Führungsstil [Greenleaf77] stellt das Dienen

am Geführten, Empathie und die Entwicklung der Mitarbeitenden in den Vorder-

grund. Bei einer KI als Geführtem erübrigt sich dieses Konzept weitgehend –

eine Maschine bedarf keiner Empathie oder Förderung ihrer persönlichen Ent-

wicklung. Hingegen wirft eine dienende Haltung einer KI-Führungskraft gegen-

über menschlichen Mitarbeitern komplexe Fragen auf: Kann eine KI überhaupt

Empathie empfinden oder ethische Werte internalisieren, um im Sinne eines

„Servant Leaders“ zu handeln? Aktuell fehlen KI-Systemen die genuine Fähig-

keit zu Mitgefühl und moralischem Urteilsvermögen, was diesen Führungsansatz

im Kontext von KI zumindest stark einschränkt.

Zusammenfassend ist festzuhalten, dass klassische Theorien wie die oben genannten von

einem anthropozentrischen Paradigma ausgehen. Sie blenden die Möglichkeit aus, dass

nicht-menschliche Agenten im Führungsgeschehen eine Rolle spielen. Auch weitere tra-

ditionelle Ansätze, von transaktionaler Führung bis Laissez-Faire, betrachten weder KI als

Führende noch als Geführte. Die Folge ist eine Konzeptlücke: Weder bieten sie Leitlinien

dafür, wie Menschen KI-Systeme führen sollen, noch dafür, wie Menschen von KI-

Systemen geführt werden können. Diese Lücke motiviert die Entwicklung neuer Füh-

rungsmodelle, die den einzigartigen Eigenschaften von KI Rechnung tragen.

3 Neue Führungsmodelle im Zeitalter der KI

Um der skizzierten Konzeptlücke zu begegnen, werden drei neue Führungsmodelle vor-

geschlagen. Jedes Modell beschreibt ein unterschiedliches Verhältnis zwischen menschli-

cher Führungskraft und KI-System und adressiert spezifische Einsatzszenarien. Die Ent-

wicklung der drei Führungsmodelle basiert auf einer konzeptionellen Literaturanalyse.

Ziel war es, theoretische Ansätze und empirische Studien zu identifizieren, die Aussagen

über Führung im Zusammenspiel von Mensch und KI ermöglichen. Eingeschlossen wur-

den Beiträge mit Relevanz für Führung, Arbeitsteilung oder Governance im Kontext von

KI, mit theoretischer oder empirischer Tragfähigkeit und Anschlussfähigkeit an Projekt-

management und Vorgehensmodelle. Ausgeschlossen wurden Arbeiten, die sich aus-

schließlich auf technische Algorithmen oder rein juristische Bewertungen konzentrieren,

da diese den organisationalen Fokus verfehlt hätten.

Die drei Modelle (Supervisory, Collaborative, AI‑Led) wurden entlang von vier Dimensi-

onen entwickelt: (1) locus of control (Mensch vs. KI), (2) Koproduktionsgrad (sequenziell

vs. simultan), (3) Verantwortungszuschreibung (individuell vs. verteilt) und (4) Transpa-

renzanforderungen (Erklärbarkeit, Überwachbarkeit, Eingriffsmöglichkeiten). Alternative

Führungsansätze wie transformationale, situative oder servant leadership wurden geprüft,

erwiesen sich aber nur eingeschränkt als übertragbar. Übertragbare Elemente – z. B.

116 Jan Wehinger

Shared Leadership – wurden in das Collaborative‑Modell integriert [BaRi06]; [Yu12].

3.1 Supervisory Leadership Model (Mensch überwacht KI)

Im Supervisory Leadership Model verbleibt der Mensch in der Rolle des überwachenden

Supervisors, während KI-Systeme als ausführende Organe agieren. Dieses Modell orien-

tiert sich am klassischen Prinzip der Mensch-Maschine-Interaktion, bei dem die Maschine

weitgehend autonom operiert, der Mensch jedoch die Endverantwortung behält. Praktisch

bedeutet dies: Eine Führungskraft delegiert definierte Aufgaben oder Entscheidungen an

eine KI (z. B. die automatisierte Planung von Schichtplänen oder die initiale Bewerber-

vorauswahl durch eine KI). Die KI arbeitet selbständig innerhalb vorgegebener Parameter,

die Führungskraft überwacht die Ergebnisse und greift nur bei Bedarf korrigierend ein

[Par00].

Das Supervisory-Modell knüpft an die Supervisory Control Theory an [Sheridan87]. Diese

besagt, dass Menschen nicht jeden Schritt automatisierter Systeme manuell kontrollieren,

sondern meta-supervisorisch tätig sind: Sie setzen Ziele, monitoren die Zielerreichung

und intervenieren bei Abweichungen. Wichtig ist hierbei die richtige Aufgabenallokation

zwischen Mensch und KI. Der Mensch konzentriert sich auf diejenigen Aspekte, welche

Kreativität, kontextspezifisches Urteilsvermögen und ethische Abwägung erfordern, wäh-

rend die KI Routineaufgaben und datenlastige Analysen effizient übernimmt.

Eine zentrale Herausforderung im Supervisory-Ansatz ist das Vermeiden des sogenannten

Aus-der-Schleife-Fallens des Menschen. Wie Bainbridge schon 1983 in den „Ironies of

Automation“ darlegte, können hochautomatisierte Systeme paradoxerweise die Überwa-

chungsaufgabe für den Menschen erschweren [Bainbridge83]. Durch monotone Routine-

überwachung besteht die Gefahr, dass die menschliche Aufmerksamkeit erlahmt und im

Notfall die Eingriffsfähigkeit reduziert ist. Führungskräfte im Supervisory-Modell müssen

daher neue Kompetenzen entwickeln (siehe Kap. 5), um trotz hoher Automatisierung si-

tuativ die Kontrolle zu behalten. So sind z. B. Kenntnisse über die Funktionsweise der KI,

ein Verständnis ihrer Grenzen sowie die Fähigkeit, Warnsignale für Fehlfunktionen zu

erkennen, essenziell. Letztlich zielt das Supervisory Leadership Model darauf ab, die Stär-

ken der KI (Rechenleistung, Geschwindigkeit, Mustererkennung) zu nutzen, ohne die

menschliche Kontrolle vollständig aus der Hand zu geben: Die KI dient als verlängerter

Arm, geführt und beaufsichtigt von einer menschlichen Instanz.

3.2 Collaborative Leadership Model (Mensch-KI-Kollaboration)

Das Collaborative Leadership Model beschreibt eine Führungsbeziehung, in der Mensch

und KI partnerschaftlich zusammenwirken. Anstatt einer eindeutigen Hierarchie (wie in

3.1 und 3.3) steht hier die Kollaboration auf Augenhöhe im Vordergrund. Der Menschli-

che Leiter und die KI teilen sich Führungsfunktionen entsprechend ihrer Stärken und kon-

textuellen Anforderungen. Man kann dieses Modell als eine Erweiterung des Konzepts

Joint Cognitive Systems verstehen, bei dem Menschen und technische Systeme als ein ge-

meinsames kognitives System agieren [Hollnagel05].

In der Praxis könnte ein kollaboratives Führungsarrangement wie folgt aussehen: Eine

menschliche Führungskraft arbeitet eng mit einem KI-Assistenzsystem zusammen, das

Wer führt die KI – und wie? Oder führt die KI uns? 117

z. B. komplexe Datenanalysen durchführt und Handlungsempfehlungen generiert. Die fi-

nale Entscheidung wird im Dialog getroffen, der Mensch bringt Erfahrungswissen, Intui-

tion und ethische Betrachtungen ein, während die KI faktenbasierte Insights und mögliche

Konsequenzen liefert. Die Führungsrolle wird dynamisch geteilt: Bei Aufgaben, in denen

die KI klare Vorteile hat (etwa Big-Data-Analyse oder Vorhersagen), übernimmt sie tem-

porär die führende Rolle als Experte. In Bereichen, die menschliche Stärken erfordern

(z. B. Mitarbeiterkommunikation, Konfliktlösung, kreative Strategiebildung), bleibt der

Mensch federführend.

Dieses Modell erfordert ein hohes Maß an Koordination und Vertrauen zwischen

Mensch und KI. Beide Partner müssen die Arbeitsweise und Denklogik des anderen zu-

mindest grundlegend verstehen, um effektiv interagieren zu können. Der Mensch muss

darauf vertrauen können, dass die KI zuverlässige und unverzerrte Informationen liefert;

die KI wiederum ist so zu gestalten, dass sie die Intentionen des Menschen berücksichtigt

(Stichwort human-centered AI). Forschung zu Mensch-KI-Teams betont die Wichtigkeit

von transparenter Entscheidungsfindung und gegenseitiger Anpassungsfähigkeit in sol-

chen gemeinsamen Systemen [Hollnagel05]. Mit anderen Worten: Die KI sollte erklärbare

Ergebnisse liefern, und der Mensch sollte bereit sein, seine Entscheidungen ggf. auf Basis

der KI-Insights zu revidieren.

Ein Vorteil des Collaborative Leadership ist die Möglichkeit, Synergien zu heben:

Menschliche und künstliche Intelligenz ergänzen sich, sodass das Gesamtteam leistungs-

fähiger ist als jede Partei für sich. Dieses Prinzip zeigt sich beispielsweise in der Praxis

von human-in-the-loop-Systemen, etwa in der Medizin oder Luftfahrt, wo Mensch und KI

gemeinsam kritische Entscheidungen fällen. Allerdings entstehen auch neuartige Prob-

leme: Wer trägt die Verantwortung bei gemeinsam getroffenen Fehlentscheidungen? Wie

werden Konflikte zwischen menschlicher Intuition und KI-Empfehlung gelöst? Solche

Fragen machen deutlich, dass das Collaborative Model robuste Governance-Mechanismen

und eine ausgeprägte Fehlerkultur erfordert, damit die Kooperation nicht im Chaos endet

(siehe Kap. 6).

Erfolgsfaktoren sind zusammenfasend Rollen‑Klarheit, shared situation awareness

[End95], transparente Schnittstellen und Vertrauenskalibrierung [Am19]; [Klei04]). Ein

Praxisbeispiel ist hierfür zum Beispiel: Qualitätsprüfung mit Computer‑Vision und

menschlicher Freigabe.

3.3 AI-Led Leadership Model (KI führt Mensch)

Das dritte Modell dreht die traditionelle Führungslogik um: Hier übernimmt ein KI-Sys-

tem selbst die Rolle des führenden Akteurs gegenüber menschlichen Mitarbeitern. Im AI-

Led Leadership Model trifft die KI weitgehend autonom Entscheidungen, weist Aufgaben

zu und überwacht deren Umsetzung, der Mensch befindet sich auf der Seite des Geführten.

Dieses Szenario ist nicht mehr futuristisch, sondern bereits heute in Ansätzen Realität:

Man spricht im Organisationskontext von algorithmischem Management, wenn digitale

Plattformen oder Algorithmen klassische Managementfunktionen ausüben [Kellogg20].

Beispiele finden sich vor allem in der Plattformökonomie und Gig-Economy: Bei Fahr-

dienstleistern, Lieferdiensten oder Crowdworking-Plattformen werden Arbeitsaufträge,

Leistungsbewertungen und Sanktionen oft vollautomatisch durch Algorithmen gesteuert.

118 Jan Wehinger

Mitarbeiter unterliegen dann faktisch einer KI-basierten Führungsinstanz, auch wenn

diese nicht in menschlicher Gestalt auftritt.

Ein charakteristisches Merkmal des AI-Led Models ist die Skalierbarkeit und Unmittel-

barkeit der Führung: Eine einzelne KI kann theoretisch Tausende von Mitarbeitern

gleichzeitig koordinieren, indem sie in Echtzeit Daten auswertet und individuelle Anwei-

sungen gibt. Die Führungsinterventionen erfolgen oft direkt über digitale Kanäle (App,

Softwareinterface) und sind konsistent nach den programmierten Regeln. Subjektive Un-

gleichbehandlung oder Ermüdungserscheinungen, typische Probleme bei menschlichen

Führungskräften, entfallen weitgehend. Allerdings treten an deren Stelle neue Herausfor-

derungen: Algorithmen folgen strikt ihren Programmierungen und den Daten, auf denen

sie trainiert wurden. Daraus können Intransparenz und Bias-Probleme erwachsen. Mitar-

beiter erleben die Führung durch eine KI mitunter als unpersönlich oder unfair, insbeson-

dere wenn Entscheidungen nicht nachvollziehbar sind oder das System auf ungewöhnliche

Situationen starr und ohne Empathie reagiert.

Die Forschung warnt zudem vor einer möglichen Verschiebung von Macht und Kontrolle

im AI-Led Modell. Kellogg et al. sprechen von einem „neuen umkämpften Terrain der

Kontrolle“, da Algorithmic Management etablierte Machtstrukturen in Organisationen

verändert [Kellogg20]. Mitarbeitende könnten das Gefühl entwickeln, einem unberechen-

baren, nicht ansprechbaren Vorgesetzten gegenüberzustehen. Die Gefahr der Entstehung

neuer Machtasymmetrien ist hierbei evident [Lee15]; [RoSt16]; [PaPa21]. Gleichzeitig

haben Top-Manager die Möglichkeit, durch KI-Systeme eine lückenlose Überwachung

und Steuerung der Belegschaft umzusetzen, was Fragen des Datenschutzes und der Ar-

beitswürde aufwirft. Dieses Spannungsfeld bedingt, dass das AI-Led Model unbedingt mit

geeigneten Governance-Strukturen und ethischen Leitplanken versehen werden muss (de-

tailliert in Kap. 6).

Trotz aller Probleme bietet KI-geführte Führung auch Chancen: In Bereichen mit klar

messbaren Zielen und reichlich Daten können Algorithmen unter Umständen objektivere

und schnellere Entscheidungen treffen als Menschen, etwa bei der Schichtplanung unter

Berücksichtigung unzähliger Präferenzen und Restriktionen, oder bei der Qualitätskon-

trolle von Prozessen in Echtzeit. Solche Stärken auszuschöpfen, ohne die Akzeptanz der

menschlichen Mitarbeiter zu verlieren, ist die zentrale Herausforderung dieses Modells.

Es erfordert von Organisationen eine neue Form der Meta-Führung: Die KI-Leitung muss

selbst wieder durch Menschen indirekt geführt und kontrolliert werden, beispielsweise

durch regelmäßige Überprüfung der Algorithmen auf Fairness und Zielkonformität,

durchgeführt von entsprechenden Experten (siehe AI Governance Officer in Kap. 5).

4 Relevante Theorien und Konzepte zur Untermauerung

Zur theoretischen Fundierung der vorgestellten Modelle lohnt ein Blick auf bestehende

Forschungsstränge, die sich mit Mensch-Technik-Interaktion und algorithmischer Ent-

scheidungsfindung beschäftigen. Insbesondere drei Konzepte bieten wertvolle Anknüp-

fungspunkte:

• Supervisory Control Theory: Diese Theorie aus der Human-Factors-Forschung

Wer führt die KI – und wie? Oder führt die KI uns? 119

beschreibt das Zusammenspiel von Mensch und Automation in hochautomati-

sierten Systemen [Sheridan87]. Gemäß Sheridan handelt es sich bei der Mensch-

KI-Interaktion nicht um eine komplette Ablösung des Menschen, sondern um

eine verteilte Kontrollstruktur: Der Mensch setzt Ziele und überwacht, die Ma-

schine führt aus. Relevante Teilkonzepte sind u. a. die Automatisierungsgrade

sowie das Phänomen der Out-of-the-loop-Problematik, das Bainbridge hervorge-

hoben hat [Bainbridge83]. Für das Supervisory Leadership Model liefert diese

Theorie die Grundlage: Sie legitimiert, dass der Mensch die finale Kontrolle be-

hält, und warnt zugleich vor Fallstricken bei Über- oder Unterautomation. Prak-

tisch fließt dies z. B. in Gestaltungsempfehlungen für assistenzsystemgestützte

Führung ein, wie Alarme, Dashboard-Anzeigen oder Notfall-Übersteuerungs-

möglichkeiten gestaltet sein müssen, damit die menschliche Führungskraft effek-

tiv die Aufsicht wahrnehmen kann.

• Joint Cognitive Systems: Das Konzept der gemeinsamen kognitiven Systeme

nach Hollnagel und Woods [Hollnagel05] betrachtet Mensch und technische Sys-

teme als Einheit, die gemeinsam kognitive Aufgaben bewältigen. Es betont, dass

weder der Mensch allein noch die Maschine allein die optimale Leistung erbringt,

sondern nur ihr Zusammenspiel. Wichtige Aspekte sind gemeinsame Situations-

bewertung, Kommunikationsschnittstellen und die Anpassungsfähigkeit beider

Partner. Dieses Konzept passt ideal zum Collaborative Leadership Model, in

dem Mensch und KI kooperativ führen. Es liefert theoretische Leitplanken dafür,

wie Arbeitsaufteilungen gestaltet werden können, wie gegenseitiges Lernen statt-

finden kann und wie Fehlerresilienz im Verbund erreicht wird. Ein Joint Cogni-

tive System erfordert beispielsweise, dass die KI über Modelle des menschlichen

Partners verfügt (um vorherzusehen, welche Informationen dieser als Nächstes

benötigt) und dass der Mensch ein grundlegendes Verständnis der KI-Logik hat

(um Entscheidungen nachvollziehen zu können). Die Theorie unterstreicht auch,

dass Verantwortung in gemeinsamen Systemen geteilt wird, ein Aspekt, der für

Governance und Haftung in Kollaborationsszenarien relevant ist.

• Algorithmic Management: Dieser Begriff beschreibt den Einsatz von Algorith-

men zur Wahrnehmung von Managementaufgaben, insbesondere in digitalen

Plattformen und datengetriebenen Organisationen [Kellogg20]. Theoretische Ar-

beiten zum algorithmischen Management analysieren, wie Entscheidungsregeln

im Code festgelegt werden, wie Leistungsdaten gesammelt und ausgewertet wer-

den und wie darauf basierend steuernde Interventionen erfolgen (z. B. automati-

sierte Bonus- oder Sanktionssysteme). Für das AI-Led Leadership Model bildet

dieses Forschungsfeld die zentrale Wissensbasis. Es erklärt, welche Mechanis-

men KI als Führungskraft erfolgreich oder problematisch machen. Etwa zeigte

Forschung, dass algorithmische Führung tendenziell transaktional geprägt ist,

d. h. sie operiert mit klaren Regeln, Belohnungen und Strafen, während transfor-

mationale Elemente (Inspiration, Kulturvermittlung) schwer umzusetzen sind.

Ebenso werden Phänomene wie Opazität (Black-Box-Entscheidungen) und feh-

lende Rechenschaftspflicht diskutiert: Algorithmen führen zu einer Verlagerung

von Entscheidungsverantwortung vom einzelnen Manager zu einem technischen

System, was neue Fragen nach Accountability aufwirft. Das theoretische Funda-

ment aus diesem Bereich hilft, Gestaltungsansätze für KI-geleitete Führung zu

120 Jan Wehinger

formulieren, z. B. Anforderungen an Transparenz (Erklärbarkeit der Entschei-

dungen) oder an Kontrollinstanzen (z. B. Audits der KI-Entscheidungen).

Darüber hinaus fließen weitere Konzepte in die Debatte ein. So fordern Ethikforscher eine

„Society-in-the-Loop“-Herangehensweise, bei der gesellschaftliche Werte und Rück-

kopplungsschleifen in algorithmische Entscheidungen eingebettet werden [Rahwan19].

Auch das Prinzip der menschenzentrierten KI (Human-Centered AI) mahnt an, dass trotz

technologischer Möglichkeiten immer die Humankontrolle und -würde gewahrt bleiben

soll. Insgesamt bieten diese Theorien einen Bezugsrahmen, um die neuen Führungsmo-

delle nicht nur konzeptionell zu verstehen, sondern auch praktisch auszugestalten. Sie zei-

gen, dass die Integration von KI in Führung weder völlig neu noch völlig unproblematisch

ist, es gibt bereits Erkenntnisse, auf denen man aufbauen kann, aber auch bekannte Fallen,

die es zu vermeiden gilt.

5 Neue Rollen und Kompetenzen

Die Etablierung von KI in Führungsprozessen erfordert nicht nur neue Modelle und The-

orien, sondern auch neue Organisationsrollen sowie erweiterte Kompetenzen bei Füh-

rungskräften. Im Zuge von New Work 2.0 zeichnen sich einige spezifische Rollenprofile

ab, die in Unternehmen geschaffen werden, und bestehende Rollen, insbesondere Füh-

rungskräft, müssen zusätzliche Fähigkeiten aufbauen.

5.1 Neue Rollen

• AI Governance Officer: Viele Unternehmen setzen zunehmend Verantwortli-

che ein, die speziell die Steuerung und Überwachung von KI-Systemen koordi-

nieren. Ein AI Governance Officer (gelegentlich auch AI Ethics Officer genannt)

entwickelt Richtlinien für den KI-Einsatz, überwacht deren Einhaltung und fun-

giert als Schnittstelle zwischen Management, IT-Entwicklung und ggf. Regulie-

rungsbehörden. Diese Rolle ist im AI-Led Leadership Model besonders wichtig:

Sie soll sicherstellen, dass KI-Führungssysteme transparent, fair und im Einklang

mit Unternehmenswerten agieren. Konkret könnte ein AI Governance Officer

z. B. regelmäßige Audits der Entscheidungsalgorithmen durchführen, ein inter-

nes Kontrollgremium für KI-Entscheidungen leiten und im Fall von Unregelmä-

ßigkeiten als Eskalationsinstanz dienen. Damit übernimmt er gewissermaßen die

indirekte Führung der KI, indem er die Rahmenbedingungen für deren Handeln

definiert und kontrolliert.

• Human-KI-Integrator: Diese neue Rolle kümmert sich um die reibungslose In-

tegration von KI-Systemen in menschliche Arbeitsprozesse. Ein Human-KI-In-

tegrator (auch Hybrid Team Manager genannt) versteht sowohl die technischen

Funktionsweisen der KI als auch die Arbeitsweise der menschlichen Teams. Er

hilft, die Aufgaben optimal zwischen KI und Mitarbeitern zu verteilen, moderiert

die Zusammenarbeit und übersetzt bei Verständnisproblemen. Im Collaborative

Leadership Model ist ein solcher Integrator zentral: Er fördert die Akzeptanz der

Wer führt die KI – und wie? Oder führt die KI uns? 121

KI unter den Beschäftigten, schult die Mitarbeiter im Umgang mit KI-Werkzeu-

gen und passt bei Bedarf Prozesse an, wenn die Zusammenarbeit stockt. Auch

fungiert er als Kommunikationskanal, er sammelt Feedback von Mitarbeitern

über die KI (z. B. über Probleme oder Verbesserungsvorschläge) und vermittelt

dieses an die Entwickler oder das Management weiter. In gewisser Weise ist der

Human-KI-Integrator ein Change Manager speziell für KI-gestützte Verände-

rungsprozesse.

(Weitere mögliche Rollen: Manch ein Unternehmen führt beispielsweise Data Stewards

oder Automation Leads ein, die ähnlich gelagerte Aufgaben haben. Auch traditionelle HR-

und IT-Rollen erweitern sich: Personalentwickler müssen etwa KI-Kompetenzen der Be-

legschaft fördern, während IT-Produktmanager stärker ethische Dimensionen beachten.)

5.2 Neue Kompetenzanforderungen

Nicht nur Spezialrollen, sondern alle Führungskräfte sehen sich mit neuen Anforderungen

konfrontiert, wenn KI Teil des Führungsalltags wird. Wichtige Kompetenzen sind u. a.:

• Technologische KI-Kompetenz: Führungskräfte müssen kein Data Scientist

sein, aber ein solides Grundverständnis für KI-Technologien ist unerlässlich.

Dazu zählt, die Funktionsprinzipien von Machine-Learning-Modellen einschät-

zen zu können, Begriffe wie Trainingsdaten, Modellgenauigkeit oder Bias zu ver-

stehen und grob zu wissen, was eine KI kann und was nicht. Nur so können sie

Entscheidungen der KI kritisch hinterfragen und sinnvolle Vorgaben für deren

Einsatz machen. Ein Manager sollte z. B. erkennen, ob ein Entscheidungsvor-

schlag der KI aufgrund eines möglichen Datenbias verzerrt sein könnte, um dann

nachzujustieren.

• Dateninterpretationsfähigkeit: Eng damit verknüpft ist die Fähigkeit, datenge-

stützte Analysen zu interpretieren. In vielen Fällen liefert die KI Analysen, Prog-

nosen oder Entscheidungsempfehlungen. Die Führungskraft der Zukunft muss

solche Outputs lesen und in den richtigen Kontext setzen können. Dazu gehört

auch, Ergebnisse mit gesundem Skeptizismus zu betrachten (Stichwort: analyti-

sche Urteilskraft). Beispielsweise will eine Führungskraft verstehen, warum ein

Algorithmus gewissen Mitarbeitern eine niedrige Performance-Prognose zuweist

und wird diese Prognose nicht unbesehen für Personalentscheidungen überneh-

men, sondern weitere Faktoren einbeziehen.

• Ethik- und Governance-Bewusstsein: Da KI-Systeme eigene Dynamiken ha-

ben, müssen Führungskräfte verstärkt als Wertewächter auftreten. Sie brauchen

Kenntnisse in Datenethik, Datenschutz und den rechtlichen Rahmenbedingungen

des KI-Einsatzes. Kompetenzen in diesem Bereich bedeuten z. B., mögliche Dis-

kriminierungsrisiken eines Algorithmus zu erkennen oder abzuschätzen, wann

menschliche Urteilsfähigkeit der „objektiven“ KI-Entscheidung überlegen ist

(z. B. in moralischen Dilemmata). Auch sollten sie mit den internen Governance-

Prozessen, etwa Freigabeschleifen für neue KI-Funktionen oder Meldewegen bei

Fehlverhalten der KI, vertraut sein und diese aktiv unterstützen. Beschäftigte und

122 Jan Wehinger

Stakeholder benötigen immer die Möglichkeit, Entscheidungen der KI anzufech-

ten. Governance sollte daher Contestability‑Kanäle und Prüfmechanismen insti-

tutionalisieren [Flo18]; [Flo23]; [Shne22].

• Interdisziplinäre Kollaboration: KI-Integration erfordert meist Teams aus ver-

schiedenen Disziplinen, Softwareentwickler, Datenanalysten, Fachexperten, Ju-

risten und die Führungskräfte selbst. Letztere müssen in der Lage sein, effektiv

in solchen interdisziplinären Teams zu arbeiten. Das heißt, sie sollten die Sprache

der Techniker und Data Scientists ausreichend verstehen, um mit ihnen Anforde-

rungen oder Probleme diskutieren zu können. Gleichzeitig vermitteln sie die Per-

spektive der Anwender und Mitarbeiter an die Technikexperten. Diese Überset-

zungs- und Brückenkompetenz wird zu einem entscheidenden Faktor, um KI-

Projekte erfolgreich in den Arbeitsalltag zu überführen.

• Soziale und kommunikative Fähigkeiten: Paradoxerweise gewinnen die ge-

nuin menschlichen Führungsfähigkeiten noch an Bedeutung. In einer Arbeits-

welt, in der KI Vieles automatisiert, werden zwischenmenschliche Aspekte zum

Differenzierungsmerkmal. Führungskräfte müssen Empathie zeigen können, um

Mitarbeiter durch Technologiewandel zu begleiten, sie müssen Veränderungen

klar kommunizieren und Vertrauen aufbauen. Gerade wenn Entscheidungen aus

einer KI kommen, ist es oft Aufgabe der Führungskraft, diese gegenüber den

Mitarbeitern nachvollziehbar zu erklären (Sensemaking) und gegebenenfalls ab-

zumildern. Eine ausgeprägte Kommunikationsfähigkeit, Geduld im Umgang mit

Ängsten der Mitarbeiter und die Fähigkeit, ein Wir-Gefühl trotz algorithmischer

Prozesse zu erhalten, sind daher wichtiger denn je.

Zusammenfassend verschiebt sich das Kompetenzprofil: Zusätzlich zu klassischen Füh-

rungsqualitäten (Strategie, Organisation, People Management) treten digitale Kompe-

tenz, Vermittlungsfähigkeiten und ethische Reflexionsstärke. Unternehmen tun gut da-

ran, ihre Leader in diesen Feldern weiterzubilden, um sie auf die Zusammenarbeit mit KI

vorzubereiten.

6 Ethische und organisationale Implikationen

Die Integration von KI in Führungsprozesse wirft eine Reihe von ethischen und organisa-

torischen Fragen auf, die es zu adressieren gilt. Einige der wichtigsten Implikationen sind:

• Verantwortung und Haftung: Wenn KI-Systeme (mit-)entscheiden, stellt sich

die Frage, wer die Verantwortung für die Entscheidungen trägt. Bei Fehlern oder

Fehlentscheidungen durch eine KI (etwa eine ungerechtfertigte Kündigung auf-

grund eines fehlerhaften Algorithmus) muss klar sein, ob die Verantwortung

beim Entwickler, beim die KI nutzenden Manager oder bei der Organisation als

Ganzes liegt. Unternehmen müssen hier klare Regelungen treffen, um Verant-

wortungsdiffusion zu vermeiden [Raji20]. Ethisch stellt sich zudem die Frage der

Zurechenbarkeit: Ein Prinzip guter Führung ist, dass Führungskräfte für ihr Han-

deln einstehen. Gilt dies auch, wenn die Entscheidung aus einer Maschine kam?

Im Sinne der Accountability sollten Unternehmen intern definieren, dass letzt-

endlich immer ein benannter Mensch die Entscheidungen einer KI verantwortet,

Wer führt die KI – und wie? Oder führt die KI uns? 123

zumal KI selbst keine moralische Verantwortung übernehmen kann.

• Transparenz und Erklärbarkeit: KI-Entscheidungen müssen nachvollziehbar

sein, insbesondere wenn sie Mitarbeiter betreffen. Black-Box-Modelle, die Füh-

rungsempfehlungen ausgeben, ohne dass deren innere Logik verstanden wird,

gefährden Vertrauen und Akzeptanz. Organisationen stehen vor der Herausfor-

derung, Erklärbarkeit (Explainable AI) sicherzustellen. Dies kann etwa bedeu-

ten, dass ein Algorithmus bei Mitarbeiterbeurteilungen die ausschlaggebenden

Faktoren mitliefert („Mitarbeiter X erhält keine Beförderung, weil Verkaufs-

quote unter Schwellenwert Y“). Auch sollten Mitarbeiter das Recht haben, Ent-

scheidungen anzufechten oder eine menschliche Überprüfung zu verlangen.

Transparenz gilt aber nicht nur gegenüber Mitarbeitern, sondern auch intern: Das

Top-Management muss Einblick in die Funktionsweise der KI haben, um strate-

gisch steuern zu können. Intransparente KI birgt das Risiko, dass sich eine Art

technokratische Unternehmenspolitik einschleicht, die selbst Führungskräfte

nicht mehr voll durchschauen, ein ethisch und organisatorisch fragwürdiger Zu-

stand.

• Bias und Fairness: Algorithmen können Vorurteile und schiefe Verteilungen

reproduzieren, wenn ihre Trainingsdaten oder Zielvorgaben voreingenommen

sind. In Führungsentscheidungen ist das fatal, man denke an eine KI, die weibli-

chen Mitarbeitern systematisch schlechtere Leistungswerte prognostiziert, weil

die historischen Daten (unbewusst) biasbehaftet waren. Unternehmen müssen da-

her aktiv für algorithmische Fairness sorgen. Das beinhaltet regelmäßige Bias-

Checks der Modelle, Diversität in den Trainingsdaten und ggf. manuelle Korrek-

turen von Entscheidungsregeln, um Diskriminierungen auszuschließen. Ethisch

geboten ist es, dieselben Gleichbehandlungsgrundsätze, die für menschliche Füh-

rung gelten, auch auf KI-Systeme anzuwenden. Organisatorisch können z. B.

Richtlinien erlassen werden, die vorschreiben, dass KI-gestützte Entscheidungen

bei Personalfragen stets von einem Menschen gegengezeichnet werden müssen,

um implizite Vorurteile abzufangen.

• Arbeitskultur und Akzeptanz: Die Einführung von KI als „Führungskraft“

kann die Organisationskultur verändern. Mitarbeiter könnten das Gefühl von

Überwachung und entmenschlichter Behandlung bekommen, wenn Anweisun-

gen nur noch von Apps oder Bots kommen. Das kann Motivation und Loyalität

beeinträchtigen. Wichtig ist daher, eine partizipative Kultur zu schaffen, in der

die Beschäftigten die Sinnhaftigkeit der KI-Integration verstehen und mitgestal-

ten können. Change-Management-Maßnahmen, offene Kommunikation über die

Ziele des KI-Einsatzes und Einbindung der Mitarbeitervertretungen sind zentrale

Stellhebel. Zudem sollte die Rolle der direkten Führungskraft neu definiert wer-

den: Sie tritt stärker als Coach und Vermittler auf, der die Brücke zwischen

Mensch und KI schlägt (vgl. Human-KI-Integrator). So kann verhindert werden,

dass Mitarbeiter sich von einer „kalten Maschine“ getrieben fühlen, ohne

menschlichen Rückhalt.

• Organisationsstruktur und Machtverteilung: KI in Führungsrollen kann Hie-

rarchien glätten, aber auch neue Zentralisierungen bewirken. Einerseits können

124 Jan Wehinger

mittlere Managementebenen wegfallen, wenn z. B. Algorithmen die Koordina-

tion großer Teams übernehmen. Andererseits konzentriert sich Macht bei denje-

nigen, die die KI-Systeme entwickeln und kontrollieren (z. B. Tech-Abteilungen

oder externe Anbieter). Dies kann zu internen Spannungen führen, wenn klassi-

sche Linienmanager Kompetenzen an Data Science Teams abgeben müssen. Or-

ganisationen sollten diese Entwicklungen im Blick haben und ggf. ihre Struktu-

ren anpassen. Möglicherweise entstehen duale Führungsstrukturen, in denen

menschliche und KI-Leitung nebeneinander existieren, hierfür sind klare Ab-

grenzungen nötig (wer entscheidet was?). Außerdem muss die Mitbestimmung

neu gedacht werden: Wenn Software Entscheidungen trifft, wie kann z. B. ein

Betriebsrat darauf Einfluss nehmen? Unternehmen könnten etwa vor Einführung

einer KI-Führungssoftware die Arbeitnehmergremien einbinden und Transpa-

renz über die Entscheidungslogik herstellen, um Akzeptanz und Legitimation zu

erreichen.

Insgesamt sind ethische und organisationale Implikationen eng verwoben: Eine verant-

wortungsvolle, menschzentrierte KI-Führungskultur wird zum entscheidenden Erfolgs-

faktor. Unternehmen, die KI-gestützte Führung einführen, müssen nicht nur technische,

sondern auch kulturelle Leitplanken setzen, um Vertrauen und Produktivität in Einklang

zu bringen.

7 Handlungsempfehlungen für Unternehmen

Vor dem Hintergrund der analysierten Modelle und Implikationen lassen sich für Unter-

nehmen, die KI im Führungsbereich einsetzen (oder dies planen), folgende Handlungs-

empfehlungen ableiten:

• KI-Strategie und Leitbild verankern: Entwickelung einer klaren Strategie, wa-

rum und wie KI in der Führung eingesetzt werden soll. Dieses Leitbild sollte die

Vorteile betonen (Effizienz, Datenbasis) und gleichzeitig festhalten, dass der

Mensch im Zentrum bleibt (KI als Werkzeug zur Unterstützung, nicht als Selbst-

zweck). Kommunikation dieses Leitbildes offen im Unternehmen, um Ängsten

und Spekulationen vorzubeugen.

• Governance-Strukturen etablieren: Einrichtung von Gremien oder Verant-

wortlichkeiten, die den KI-Einsatz überwachen. Dies kann ein AI Governance

Board sein oder die Benennung eines AI Governance Officers mit entsprechen-

den Befugnissen. Definition von Richtlinien (z. B. ein KI-Ethik-Kodex), die fest-

schreiben, welche Entscheidungen KI treffen darf und wo zwingend ein Mensch

involviert sein muss (human-in-the-loop Prinzip). Laufende Überwachung der

Einhaltung dieser Leitplanken.

• Transparenz und Partizipation sichern: Bevor KI-Systeme mit Führungsauf-

gaben live gehen, müssen Mitarbeiter einbezogen werden. Funktionsweise und

Zweck der Systeme müssen in verständlicher Sprache erklärt und vermittelt wer-

Wer führt die KI – und wie? Oder führt die KI uns? 125

den. Die Einrichtung von Feedback-Kanälen ist zu empfehlen, über die Mitarbei-

ter Erfahrungen mit KI-Entscheidungen rückmelden können. Piloten oder Test-

phasen müssen an die Strategiefelder des Unternehmens gekoppelt sein. Die Ein-

führung sollte grundsätzlich schrittweise und mit Möglichkeit zur Kurskorrektur

erfolgen.

• Weiterbildung und Kulturwandel fördern: Investition in Trainings für Füh-

rungskräfte und Mitarbeiter, um KI-Kompetenzen aufzubauen ist ratsam. Dies

umfasst technische Grundkenntnisse ebenso wie Schulungen zu Datenschutz

oder algorithmischer Fairness. Gleichzeitig sollte der Kulturwandel begleitet

werden: Förderung eines Mindset, das Offenheit gegenüber Technologie mit hu-

manistischen Werten verbindet. Führungskräfte sollten z. B. lernen, wie sie Ent-

scheidungen einer KI ihren Mitarbeitern vermitteln und dabei empathisch auf

Sorgen eingehen (digital empathy).

• Technische Gestaltung: menschenzentriert & erklärbar: Die Auswahl oder

Eigenentwicklung von KI-Systeme sollten dem Postulat der Erklärbarkeit folgen.

Das heißt, dass sie erklärbare Ausgaben liefern (Stichwort Explainable AI). Dies

kann beispielsweise die Implementierung von einem KI-Dashboard sein. Gene-

rell steht im Vordergrund, dass bei der Entwicklung von Algorithmen auf quali-

tativ hochwertige, repräsentative Trainingsdaten geachtet werden muss, um Bias

zu minimieren. Das Testing der Systeme vor breitem Einsatz auf unerwünschte

Verhaltensweisen ist immer durchzuführen.

• Pilotanwendungen gezielt auswählen: Ratsam ist, den KI-Einsatz in Bereichen

zu starten, die überschaubar und gut kontrollierbar sind. Beispielsweise kann ein

Chatbot als virtueller Teamleiter für einfache Routineaufgaben in einem kleinen

Team getestet werden, bevor man großflächig algorithmisches Management ein-

führt. Diese Piloten müssen analysiert werden um aus Erfolgen und Misserfolgen

zu Lernen. Eine Skalierung der KI in der Führung sollte erst stattfinden, wenn

Prozesse feinjustiert und Mitarbeiter abgeholt sind.

• Kontinuierliche Evaluation: Abschließend gilt es regelmäßige Audits und Er-

folgskontrollen durchzuführen. Dies umfasst die Messung von z. B. Mitarbeiter-

zufriedenheit und -leistung unter KI-geführter Führung vs. traditioneller Füh-

rung, um Auswirkungen zu quantifizieren. Weiterhin sollte überprüft werden, ob

die KI-Entscheidungen mit den Unternehmenswerten und -zielen im Einklang

stehen. Dies kann durch externe Experten oder Ethikräte ergänzt werden, die sen-

sibel Bereiche begutachten (etwa Algorithmen zur Personalsteuerung), um blinde

Flecken zu vermeiden. Diese ständige Lernschleife ermöglicht es, frühzeitig ge-

genzusteuern, falls negative Effekte auftreten.

Durch beherzigte Umsetzung dieser Empfehlungen können Unternehmen die Potenziale

von KI in der Führung nutzen und zugleich Risiken beherrschen. Entscheidend ist ein

ganzheitlicher Ansatz: Technik, Mensch und Organisation müssen synchronisiert werden,

damit KI als Führungsinstrument tatsächlich zu besseren Ergebnissen führt, für das Un-

ternehmen und die Menschen, die darin arbeiten.

126 Jan Wehinger

8 Fazit

Künstliche Intelligenz verändert die Spielregeln der Führung in der modernen Arbeitswelt.

Klassische Führungstheorien stoßen an ihre Grenzen, wenn nicht mehr ausschließlich

Menschen, sondern auch KI-Systeme als Führende oder Geführte auftreten. In diesem Bei-

trag wurden drei neue Führungsmodelle, Supervisory, Collaborative und AI-Led Lea-

dership, vorgestellt, die unterschiedliche Aufteilungen von Verantwortung und Kontrolle

zwischen Mensch und Maschine beschreiben. Wir haben gesehen, dass jedes Modell

Chancen bietet (Effizienz, neue Synergien, Objektivität), aber auch spezifische Risiken

birgt (Kontrollverlust, Akzeptanzprobleme, ethische Dilemmata).

Entscheidend ist, dass die Einführung von KI in Führungsrollen bewusst gestaltet wird.

Der Mensch darf sich nicht selbst überflüssig machen: Selbst im Zeitalter der Automati-

sierung bleibt Führung letztlich eine zutiefst menschliche Aufgabe, nämlich Sinn zu stif-

ten, Vertrauen zu schaffen und Werte zu wahren. KI kann hierbei ein mächtiges Werkzeug

sein, um informierte Entscheidungen zu treffen und komplexe Prozesse zu steuern. Doch

wer führt die KI? Diese Frage muss jedes Unternehmen für sich beantworten, indem klare

Verantwortlichkeiten und Governance geschaffen werden. Ebenso wichtig ist die Frage

„wie“: Es bedarf neuer Kompetenzen, Rollen und Regeln, um das Zusammenspiel von

menschlicher und künstlicher Intelligenz im Führungsprozess erfolgreich zu gestalten.

Insgesamt steht Führung im Kontext von New Work 2.0 vor einem Paradigmenwechsel.

Die Organisationen, die es schaffen, KI-Technologie mit einer humanistischen Führungs-

kultur zu vereinen, werden einen entscheidenden Wettbewerbsvorteil haben. Die vorlie-

genden Überlegungen sollen einen Beitrag dazu leisten, diesen Wandel besser zu verste-

hen und aktiv zu gestalten. Weitere Forschungen und praktische Erfahrungen, etwa zu den

langfristigen Auswirkungen KI-geführter Teams auf Innovation und Zufriedenheit, blei-

ben notwendig, um die Führungsmodelle der Zukunft laufend zu verfeinern. Eines jedoch

ist klar: Die Frage ist nicht mehr, ob KI die Führung verändert, sondern wie wir mit diesen

Veränderungen umgehen.

Literaturverzeichnis

[Am19] B Amershi, S., Weld, D., Vorvoreanu, M., Fourney, A., Nushi, B., Collisson, P.,

et al. (2019). Guidelines for Human-AI Interaction. In Proceedings of CHI.

ACM.

[Bainbridge83] Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779.

[BaRi06] Bass, B. M., & Riggio, R. E. (2006). Transformational Leadership (2nd ed.).

Lawrence Erlbaum, Mahwah, NJ.

[Bass94] Bass, B. M., & Avolio, B. J. (1994). Improving Organizational Effectiveness

through Transformational Leadership. Sage Publications.

[End95] Endsley, M. R. (1995). Toward a theory of situation awareness in dynamic sys-

tems. Human Factors, 37(1), 32–64.

[Flo23] Floridi, L. (2023). The ethics of artificial intelligence for a good AI society. AI

& Soci-ety, 38, 1–14.

Wer führt die KI – und wie? Oder führt die KI uns? 127

[Flo18] Floridi, L., Cowls, J., Beltrametti, M., et al. (2018). AI4People – An ethical

framework for a good AI society. Minds and Machines, 28, 689–707.

[Greenleaf77] Greenleaf, R. K. (1977). Servant Leadership. Paulist Press.

[Hersey69] Hersey, P., & Blanchard, K. H. (1969). Life cycle theory of leadership. Training

and Development Journal, 23(2), 26–34.

[Hollnagel05] Hollnagel, E., & Woods, D. D. (2005). Joint Cognitive Systems. CRC Press.

[Kellogg20] Kellogg, K. C., Valentine, M. A., & Christin, A. (2020). Algorithms at work.

Academy of Management Annals, 14(1), 366–410.

[Klei04] Klein, G., Woods, D. D., Bradshaw, J. M., Hoffman, R. R., & Feltovich, P. J.

(2004). Ten challenges for making automation a 'team player'. IEEE Intelligent

Systems, 19(6), 91–95.

[Lee15] Lee, M. K., Kusbit, D., Metsky, E., & Dabbish, L. (2015). Working with ma-

chines: The impact of algorithmic and data-driven management on human

workers. In Proceedings of CSCW (pp. 1603–1612). ACM.

[Par00] Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types

and levels of human interaction with automation. IEEE Transactions on Sys-

tems, Man, and Cybernetics – Part A, 30(3), 286–297.

[PaPa21] Parent-Rocheleau, X., & Parker, S. K. (2021). Algorithms as managers: Impli-

cations for work design. Human Resource Management Review, 31(1), 100747.

[Raji20] Raji, I. D., Smart, A., White, R. N., Mitchell, M., Gebru, T., Hutchinson, B., et

al. (2020). Closing the AI accountability gap: Defining, evaluating, and auditing

AI systems. In Proceedings of ACM FAccT.

[Rahwan19] Rahwan, I., et al. (2019). Machine behaviour. Nature, 568(7753), 477–486.

[Sheridan87] Sheridan, T. B. (1987). Supervisory control. In Handbook of Human Factors.

Wiley.

[RoSt16] Rosenblat, A., & Stark, L. (2016). Algorithmic labor and information asymme-

tries – A case study of Uber’s drivers. International Journal of Communication,

10, 3758–3784.

[Shne22] Shneiderman, B. (2022). Human-Centered AI. Oxford University Press, Oxford.

[Yukl12] Yukl, G. (2012). Effective leadership behavior. Academy of Management Per-

spectives, 26(4), 66–85.

128

Teil II

Beiträge der Session „Future Track“

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 131

Post Agility – A Review and Outlook

Sarah Brandt1, Sven Theobald2, Pascal Guckenbiehl3 und Alexander Krieg4

Abstract: Agile software development approaches are widely used due to their many benefits. Re-

cently, the term "Post Agility” or “Post Agile" has gained traction in discussions surrounding Agile

software development. This paper aims to explore the significance and implications of this emerging

concept, questioning whether it is merely a buzzword used in the consulting world or if it holds

substantial meaning for the future of software development and organizations in general. With the

help of a literature review, we delve into the origins, definitions and characteristics of Post Agility.

We then discuss potential approaches that may become increasingly relevant in this evolving land-

scape, namely agile leadership and vibe coding. Our findings provide a summary and insights on the

paradigm as well as inspiration for future research.

Keywords: Post Agility, Post Agile, Post Agilism, Agile Leadership, Vibe Coding

1 Introduction

Agile software development approaches are widely used due to their many benefits. Ini-

tially utilized by small teams developing information systems, they were later scaled to

larger projects with the help of scaling frameworks [Th19] and even applied for the devel-

opment of more complex or regulated products, e.g., for embedded systems [DT18]. The

Agile Manifesto [Be01] stands out for its effort to balance the competing priorities of cus-

tomers, management, and development teams. Rather than replacing traditional processes,

Agile complements them with principles that emphasize customer collaboration and team

autonomy, while management largely remains in the background [BNY17].

However, the Agile Manifesto does not specify how its principles should be operational-

ized in practice. Although it has strongly influenced software development, there remains

a lack of clarity on how to institutionalize Agile in sustainable ways, leading to growing

skepticism about its current direction. There are increased discussions within the Agilist

community about Post Agility, combined with many statements that claim “Agile is dead”.

But what does that mean? Are the principles, methods and practices not suited for the

current challenges in software development and organizations in general, or did they al-

ready become state of the practice?

The aim of this work is to better understand the term “Post Agile” by reviewing scientific

literature and investigating the origin of this movement and possible definitions. In addi-

tion, we share our thoughts on the topic and provide an outlook on what could possibly be

1 Fraunhofer-Institute for Experimental Software Engineering, Smart City Design, Fraunhofer-Platz 1, 67663

Kaiserslautern, sarah.brandt@iese.fraunhofer.de

2 Fraunhofer-Institute for Experimental Software Engineering, Data Science, Fraunhofer-Platz 1, 67663 Kai-

serslautern, sven.theobald@iese.fraunhofer.de

3 TOPdesk Deutschland GmbH, Carl-Euler-Straße 8, 67663 Kaiserslautern, p.guckenbiehl@topdesk.com

4 vimoki GmbH, Geschäftsführung, Stadtdeich 2-4, 20097 Hamburg, alexander.krieg@vimoki.de

132 Sarah Brandt et al.

the new way of working after Agile processes. The paper is structured as follows: Section

2 explains the research goal and questions which we aimed to address. Section 3 summa-

rizes findings from the literature review to better understand what Post Agility is about.

Section 4 extends this with further thoughts and an outlook going forward. Section 5 con-

cludes this paper with the main takeaways.

2 Research Goal & Method

The goal of our research was to investigate Post Agility, specifically where the concept

originated from, how it is defined and what implications for the future might be. We started

with a review of scientific literature, to answer the following research questions:

• RQ1: When and why did Post Agile as a concept emerge, and what has driven its

growing significance over time?

• RQ2: How is Post Agile defined, and how does it conceptually and practically di-

verge from the Agile paradigm?

Although not following a strict approach for a systematic literature review, we aimed to

conduct a complete review of the scientific literature. Hence, we defined a broad search

string (“post agil*” OR “post-agil*”) and conducted a literature search on Scopus in May

2025, searching within title, abstract and keywords. From the 10 results, we excluded two

conference proceedings and one book chapter, as well as one paper we could not gain

access to. The remaining 6 literature sources all fulfill our only inclusion criterion by men-

tioning the term “Post Agility/ Post Agile”. The identified papers [BPM11] [DOM13]

[DOM14] [LS15] [Le15] [Kn17] were all peer-reviewed publications dating back to the

2010s, we could not find any preprints on this topic. One Portuguese paper [LS15] needed

to be translated into English with the help of a translation tool.

Only having this small number of papers to review, we skipped the typical study selection

process of first filtering by title and abstract before analyzing the full text and directly did

a review of the full paper. In addition, we looked at Google Scholar for other scientific

papers that provided insights into Post Agility or the claim that “Agile is dead”. To achieve

a more complete and up-to-date picture, we further conducted an unsystematic and incom-

plete search for non-scientific literature. From all identified sources, we extracted the in-

formation along the research questions and collected all relevant information in a table.

Finally, we answered the research questions based on the extracted information and added

our own thoughts via the discussion.

3 Origin & Definition of Post Agility

This section describes the results of our literature review along the two research questions

introduced above. It revolves around understanding where the term originated and how it

is defined through an overview of individual ideas and common themes.

Post Agility – A Review and Outlook 133

3.1 Origin (RQ1)

The authorship of the term “Post Agilism” that originated in mid 2006 was attributed to

Jonathan Kohl and Jason Gorman, simultaneously [LS15] [Ko07]. Kohl [Ko07] defines

Post Agilism as either “an emerging era” after Agile became mainstream, or as “a growing

movement of former Agilists who have moved beyond Agile methods” and provides in-

sights on his thoughts: The term “Post Agilism” was inspired by modernism and post-

modernism, seen in architecture and the arts. Agile is comparable to modernism due to its

progressive vision, with many rules around its values and tools. Analogous to post-

modernism, Post Agilism breaks rules to create new, hybrid processes. When many devel-

opment teams moved to Agile methodologies, a commercial niche was created and certif-

icates, trainings, books as well as consulting businesses boomed [LS15]. Principles and

methods were no longer reflected or adapted to the context at hand, instead the practices

were seen as rules that needed to be followed. Thus, the term “Post Agile” was coined to

motivate developers to be more skeptical and use practices from both traditional and Agile

methods that are suitable for their context. It was not the intention of Kohl to provide a

definition of Post Agility in the form of new practices or principles.

However, later use of the term is related to defining such new principles and practices,

especially regarding faster feedback and continuous delivery/ DevOps [Le15] [BNY17]

[DOM13] [Co19]. Most of those authors describe Post Agility as the result of a natural

evolution. When conditions are changing, software development needs to adapt. Examples

of such conditions are:

• Changing economics and the role of software in formulating business solutions and

generating revenue [BPM11]

• Pressure to favor releasing early over quality for low cost, rapid development and

to code for new features [DOM13]

• Fast and continuous delivery is needed - rapid development and fast feedback cycles

[Le15]

• Fast iteration, missing contact to costumer, information loss [BNY17]

• Fast feedback, the use of Agile values outside of product design and simplification

of processes [Co19]

Our literature review revealed that the most recent scientific publication explicitly refer-

encing the term “Post Agile” dates back to 2017. Since then, two notable trends have

emerged. First, there appears to be a lack of continued academic engagement with the term

itself. This absence may be attributed either to the term's conceptual vagueness or to the

rise of newer paradigms (such as DevOps or Continuous Delivery) which have shifted the

focus of discourse away from Post Agile as a relevant category.

In contrast, the term continues to generate significant discussion in non-academic contexts,

particularly in social media and industry blogs. Here, Post Agile serves as a focal point for

debates about the limitations of established Agile practices. These discussions are pre-

dominantly driven by consultants and practitioners who work with Agile methodologies

on a daily basis and are directly confronted with the practical challenges of applying them

in evolving organizational environments.

134 Sarah Brandt et al.

3.2 Definition (RQ2)

The literature sources deal with the term “Post Agile” in different depths. [BPM11] evalu-

ate historical developments in software engineering resulting in a recurring pattern, where

dramatic market changes led to a disruption of established practices, which is then fol-

lowed by process adaptation. Based on history, the authors offer a perspective on Post

Agility. [Kn17] also follows the development history from Waterfall to Agile to Post Ag-

ile. From a definition of Agile, the author concludes that Agile will develop into Post

Agile. Similarly, [LS15] conclude the change from Agile to Post Agile, however the au-

thors use the modernist to post-modernist movement as comparison to the movement from

Agile to Post Agile as the starting point of their discussion. [DOM13] as well as [DOM14]

mention Post Agility, but they do not define or explain the term. The authors claim that

Agile practices need to develop, where the result may be called Post Agility. [Le15] men-

tions the term “Post Agile”, discussing where and why Agile frameworks don’t anymore

and describing Continuous Delivery regarding what comes next. A similar approach is

used by [BNY17], who evaluate the history of Agility and how it will develop, describing

DevOps as the next step. The authors further evaluate which Agile will principles remain.

Despite the growing discourse around Post Agility and its increasing presence in literature,

a precise and consistent definition has yet to be established. Several authors introduce

DevOps or Continuous Delivery as the next step after Agile. Others agree that there is a

need to evolve from Agile into a new era as established methods cannot address today's

challenges. For some (like [Em17]), Post Agile means the use of Agile principles in new

processes. The following statements provide an overview of interpretations:

• “[…], by ‘‘Post Agility’’ we do not imply the end of agility; rather it refers to a deep

incorporation of agility into all modes of software development” [BPM11]

• “The term Post-Agile was then coined to register an era in which developers became

more skeptical and careful about changing the internal practices of their projects.”

[LS15]

• “We are now in the “post-Agile” age. “Post”-something means that we are in an in-

between period, where one thing has been incorporated into our culture and the next

thing has not yet formed to the point of naming.” [Co19]

• "Post Agile refers to harmonizing Agile working and asynchronous communication.

It’s a new patchwork working style that Tech Teams, especially in fully-remote

multi-time zone environments, use to merge the Agile Manifesto with state-of-the-

art asynchronous communication" [Mc22]

In conclusion, the term “Post Agile” refers to a shift away from the strict use of established

Agile frameworks, as these often no longer meet the complex and evolving demands of

today’s software development. Although some practices may be questioned or replaced,

the core ideas and values of Agile still influence how teams work - just in more flexible

and varied ways. We are currently observing a growing movement of former Agile prac-

titioners who have moved beyond the exclusive use of Agile methodologies. Instead, they

draw from a broad array of tools, practices, and approaches. This shift indicates the emer-

gence of a new phase: now that Agile has become mainstream, the question arises what

comes next.

Post Agility – A Review and Outlook 135

We intentionally refrain from offering a fixed or universal definition of Post Agility. In-

stead, we understand it as a reflection of changing conditions in the software industry that

challenge the adequacy of established Agile thinking. Agile has not disappeared, it is

evolving. This manifests in new methods, hybrid approaches, or practices that may no

longer explicitly carry the Agile label yet still embody its core intent. Post Agility therefore

should not be seen as a failure or abandonment of Agile, but rather as a continuation of its

evolution, a return to foundational values and an adaptation to a more complex and diverse

landscape.

4 Beyond Agile – A Continuous Evolution

In this section, we first discuss the development of Agile into Post Agile, by addressing

the success of agile principles as well as examining current challenges in software devel-

opment. We further describe new context and process changes by exploring two examples

of relevant topics in a Post Agile era, namely Agile Leadership and Vibe Coding.

4.1 Reflecting on Success & Challenges

Agile methodologies have fundamentally reshaped software development by emphasizing

iterative delivery, adaptive planning, and close collaboration with customers [Be01]. Cen-

tral to Agile’s success are its core principles, such as short development cycles, early and

continuous software delivery, self-organizing teams, and a focus on learning and reflection

[BNY17]. These elements have increased team motivation, improved transparency, ena-

bled early detection of defects, and enhanced overall product quality [MH13] [NIG24].

Furthermore, Agile fosters customer satisfaction through regular feedback and promotes

cross-functional teamwork, making many of its practices indispensable in today’s devel-

opment environments [OFM13] [BH21] [JNA19].

Despite these successes, Agile faces significant challenges in contemporary settings. The

increasing complexity of software systems requires practices such as Continuous Deliv-

ery/ Deployment, modular architectures like microservices, and rigorous quality assurance

integrated early in the process [BNY17]. These demands often translate into intense pres-

sure on development teams, risking burnout and reducing time available for reflective

learning. Customer involvement, a cornerstone of Agile, also encounters obstacles. Prac-

tical constraints such as time limitations, geographic distribution, and reliance on Product

Owners or proxies can degrade communication and understanding, resulting in delays,

misunderstandings, and increased costs [SH19] [Mc13]. Additionally, originally flexible

guidelines have frequently ossified into rigid frameworks with fixed ceremonies and tools,

especially in larger organizations with hierarchical structures, leading to feelings of mi-

cromanagement and limiting true agility. Lastly, many organizations struggle to scale Ag-

ile beyond small teams or within traditional environments, often emphasizing process

compliance over delivering real value and people-centered collaboration [BNY17].

Agile has not failed as a concept, but problems often arise in practical implementation and

translating the underlying principles into everyday actions. Also, one could say that Agile

at some point started to contradict itself. What was originally about an “Inspect & Adapt”

136 Sarah Brandt et al.

culture, became a rigid implementation of predefined frameworks regardless of context

and with limited scope.

4.2 Current Trends: Agile Leadership & Vibe Coding

In [BPM11], it is explicitly stated that a change in context leads to a change in process.

This observation was foundational for the emergence of agility in the first place. During

the Agile era the context evolved once again, which became evident through the chal-

lenges encountered in the practical application of Agile methods. As previously discussed,

such shifts in context imply that Agile approaches themselves need to evolve.

In our analysis, two emerging trends - Agile Leadership and Vibe Coding - can be seen as

part of this ongoing evolution. We consider both (alongside others, which we do not ad-

dress here) to be characteristic of a Post Agile era, reflecting current shifts in software

development (see Fig. 1). Importantly, these developments do not represent a departure

from agility, but rather a continuation of the core mindset. They build upon Agile princi-

ples while adapting to new organizational, technological, or social conditions.

Fig. 1. From context to process change. Adapted from [BPM11]

Agile Leadership - Agile leadership is a modern approach to leading organizations that

has emerged in response to the fast-paced, unpredictable, and complex nature of today’s

business environment, often referred to as a VUCA world (Volatile, Uncertain, Complex,

and Ambiguous). As companies face constant disruption due to digital transformation,

new competitors, and evolving customer expectations, traditional leadership models char-

acterized by centralized decision-making and rigid hierarchies have become increasingly

ineffective. Instead, organizations now need leaders who embrace agility as a core value

and who can foster adaptability, speed, and collaboration.

Post Agility – A Review and Outlook 137

Originating from software development in the 1990s, Agile principles have gradually ex-

panded beyond technical departments to influence leadership and organizational design

more broadly. Agile leadership emphasizes flexibility, responsiveness, and commitment

to continuous improvement. It is not just about adopting Agile methods but requires a

fundamental shift in mindset and behavior, particularly around empowering teams and

creating environments that support autonomy and self-organization.

More specifically, the concept can be defined by several key categories that encapsulate

Agile Leadership [Th20] [Kr22]. Among them, a focus on self-organized teams emerged

as a novel concept not found in traditional leadership models. Agile leaders further focus

on setting clear visions and goals, creating the right conditions for teams to thrive, and

maintaining a strong alignment with customer value. They also play a critical role in ena-

bling continuous learning and improvement across the organization. Importantly, Agile

leadership depends heavily on the personal qualities and commitment of leaders them-

selves, especially at the top levels of management. Typically, Agile transitions have started

bottom-up with pilots in software development. Agile leadership becomes increasingly

important now to all Agile initiatives that got stuck along the way, trying to spread agility

in a scaled environment, at the interface to traditional organizational units [TD18] and

finally throughout the whole organization [KTK18].

Vibe Coding - Vibe coding is a new topic in software development, where coding is per-

formed by AI tools. Large language models (LLMs) are generating code rather than de-

velopers. While developers express their ideas in natural language, LLMs generate code

line by line [Ni25]. The term itself was created by Andrej Karpathy in February 2025 with

the words: “I'm building a project or webapp, but it's not really coding - I just see stuff,

say stuff, run stuff, and copy paste stuff, and it mostly works.” [Ka25]. Instead of dealing

with syntax, algorithms, and debugging as a developer, the AI is doing these tasks. This

might change software development fundamentally. Vibe coding is therefore describing

what the software should do, while the AI is taking care of how to program the software

[Ni25]. This makes software development more accessible and faster, especially for pro-

totyping, ideation, or experimental projects [Wo25]. Further, users with limited technical

backgrounds or expertise in programming can generate code only using a description of

what they want. They can use tools like Cursor, Windsurf AI, GitHub Copilot, and Replit

Agent to support the process of coding using a development environment [Sc25].

Vibe coding, especially when used with structured guidance, offers a compelling comple-

ment to traditional development methodologies [La25]. Like Agile, vibe coding supports

rapid prototyping, quick iterations, and continuous refinement, except it dramatically com-

presses these cycles using AI to instantly generate and test working code based on natural

language descriptions. The fast generation of functional prototypes or full applications in

short-time makes vibe coding particularly appealing for start-ups and medium-sized en-

terprises with limited resources that must respond quickly to market changes [Sc25].

However, this approach also comes with obvious challenges. Quality might suffer if the

user of vibe coding lacks the necessary software engineering skills. Critical aspects like

safety and security cannot be ensured. Also, internal quality will be affected, e.g. reduced

maintainability and comprehension of the codebase. While vibe coding might be sufficient

for simple and uncritical applications or prototypes, real complex software products need

138 Sarah Brandt et al.

software engineers that can review and rework the generated code. From a process per-

spective, while Agile emphasizes collaboration, shared code understanding, and ongoing

feedback loops, vibe coding can become a more isolated, AI-driven process, risking re-

duced team communication. Thus, rather than replacing Agile, vibe coding should be

viewed as a “pair programmer” embedded within established Agile workflows - not as a

replacement for traditional development, but as a targeted enhancement that complements

and strengthens existing team practices [Wo25]. In practice, many teams may adopt a hy-

brid model, leveraging Agile or DevOps for structure and quality control, while integrating

AI-assisted development to accelerate feature creation, as long as key engineering princi-

ples remain intact. Vibe coding could be used in early sprints, focusing on an idea or con-

cept validation. It could be used for creating early software prototypes, which then will be

refined, reviewed and improved by developers. Such a combination of Agile methods and

vibe coding could potentially deliver the most value.

Therefore, vibe coding exhibits a strong alignment with the Agile principle of responding

to change instead of following a fixed plan. By facilitating rapid integration of feedback,

implementation of novel ideas, and continuous iteration it supports core Agile values. The

cycle of inspection an adaption in Agile frameworks can be significantly accelerated:

teams are empowered to generate code, assess outcomes, extract insights, and iterate with-

out delay [Wo25]. This hybrid model of vibe coding with Agile core principles and frame-

works might be a sustainable solution for software development: rapid prototyping and

early validation with traditional development to build and secure critical components.

5 Conclusion

Agile has profoundly shaped modern development practices - introducing flexibility, iter-

ative cycles, and customer-centricity. However, the focus shifted away from people and

delivering real value: What was originally about a mindset of inspecting and adapting

evolved into rigid implementation of predefined frameworks regardless of context and

scope. Many practitioners now are questioning whether established Agile frameworks re-

main relevant or sufficient, leading to an increased discourse about “Post Agility”.

With the help of a literature review, this paper aims to provide a better understanding of

the origin and definition of the term. Originally, Post Agile was coined in analogy to post-

modernism in arts, emphasizing flexibility, pragmatism, and adapting to context. Later,

the term was used to describe specific additions to Agile, e.g. DevOps. While there is no

scientifically based definition, Post Agile can be understood as the evolution of Agile,

adapting to increasing complexity and utilizing new tools, while retaining its core values.

We offer two examples of context-driven process changes in a Post Agile era: Agile lead-

ership and vibe coding.

Agile leadership has evolved in response to today's fast-changing, complex business en-

vironments. Unlike traditional hierarchical leadership, Agile Leadership emphasizes

adaptability, collaboration, and continuous improvement. Leaders focus on empowering

self-organized teams, setting clear goals, fostering customer alignment, and creating envi-

ronments that support autonomy and learning. With agile transitions often being stuck

with “doing agile”, agile leadership is necessary to enable “being agile” by helping to

Post Agility – A Review and Outlook 139

implement the cultural aspects of agility throughout the organization.

Vibe coding is a new trend in software development where code is written by AI based on

natural language descriptions. Vibe coding promises to speed up software development

and make it more accessible. Thus, Vibe coding complements Agile principles by enabling

rapid prototyping, fast iterations, and continuous refinement. A hybrid model combining

Agile with AI-assisted coding may offer a sustainable path forward, e.g. using AI as a

supportive “AI pair programmer” within existing workflows.

References

[Be01] Beck, K. et al.: Manifesto for Agile Software Development, http://agilemanifesto.org,

2001.

[BH21] Bambauer-Sachse, S. and Helbling, T. (2021), "Customer satisfaction with business ser-

vices: is agile better?", Journal of Business & Industrial Marketing, Vol. 36 No. 8, pp.

1389-1402. https://doi.org/10.1108/JBIM-04-2020-0221.

[BNY17] Babb, J.; Nørbjerg, J.; Yates, D. J.; and Waguespack, Leslie J., "The Empire Strikes

Back: The end of Agile as we know it?" (2017). Selected Papers of the IRIS, Issue Nr 8

(2017), 8, https://aisel.aisnet.org/iris2017/8.

[BPM11] R. Baskerville, J. Pries-Heje, und S. Madsen, „Post-agility: What follows a decade of

agility?“, Information and Software Technology, Bd. 53, Nr. 5. S. 543–555, 2011. doi:

10.1016/j.infsof.2010.10.010.

[Co19] Cockburn, A.: Post-Agile thoughts, 2019, Heart of Agile, https://heartofagile.com/post-

agile-thoughts/, latest access 16.06.2025.

[De23] S. Denning, „How Tesla’s management innovations operationalize its “Deep Purpose”

to save the planet“, Strategy and Leadership, Bd. 51, Nr. 5. Emerald Publishing, S. 3–

10, 2023. doi: 10.1108/SL-07-2023-0069.

[DOM13] P. M. Dóra, A. C. Oliveira, und J. A. B. Moura, „Improving quality in agile development

processes“, ICSOFT 2013 - Proceedings of the 8th International Joint Conference on

Software Technologies. S. 411–416, 2013. [Online]. Verfügbar unter: https://www.sco-

pus.com/inward/record.uri?eid=2-s2.0-84887051868&partne-

rID=40&md5=d0c9b4111d9fdee27fbe83595f9b9ecd

[DOM14] P. M. Dóra, A. C. Oliveira, und J. A. B. Moura, „Simultaneously improving quality and

time-to-market in agile development“, Communications in Computer and Information

Science, Bd. 457. Springer Verlag, S. 84–98, 2014. doi: 10.1007/978-3-662-44920-2_6.

[DT18] Diebold P, Theobald S. How is agile development currently being used in regulated em-

bedded domains? J Softw Evol Proc. 2018; 30:e1935. https://doi.org/10.1002/smr.1935

[Em17] Emmerich, M.: Post Agile, 2017, https://conventic.github.io/2017/04/25/post-agile/, lat-

est access 16.06.2025.

140 Sarah Brandt et al.

[JNA19] Julian, B., Noble, J., Anslow, C.: Agile Practices in Practice: Towards a Theory of Agile

Adoption and Process Evolution. In: Kruchten, P., Fraser, S., Coallier, F. (eds) Agile

Processes in Software Engineering and Extreme Programming. XP 2019. 2019. Lecture

Notes in Business Information Processing, vol 355. Springer, Cham.

https://doi.org/10.1007/978-3-030-19034-7_1

[Ka25] Karpathy, A.: Post at X regarding vibe coding. https://x.com/karpathy/sta-

tus/1886192184808149383?lang=de, 2025, latest access 07.05.2025.

[Kn17] J. Knight, „Go with the Flow: Accelerated digital design in the age of Post-agility“, De-

sign Journal, Bd. 20, Nr. sup1. Taylor and Francis Ltd., S. S2700–S2715, 2017. doi:

10.1080/14606925.2017.1352781.

[Ko07] Jonathan Kohl, 2007, Post-Agilism Frequently Asked Questions,

http://www.kohl.ca/2007/post-agilism-frequently-asked-questions/, latest access

23.06.2025

[Kr22] A. Krieg, N. Prenner, P. Guckenbiehl, S. Theobald, und K. Schneider, „A Scientific

Baseline for Agile Leadership-A Workshop Study“, 2022.

[KTK18] A. Krieg, S. Theobald, und S. Küpper, „Erfolgreiche agile Projekte benötigen ein agiles

Umfeld - Was definiert eine agile Organisation?“, in Projektmanagement und Vorge-

hensmodelle 2018. Der Einfluss der Digitalisierung auf Projektmanagementmethoden

und Entwicklungsprozesse, 2018.

[La25] Lavigne, R.: A Deep Research on Vibe Coding, using o3-mini-high, across 24 sources

in only 5 minutes., 2025, https://www.linkedin.com/pulse/deep-research-vibe-coding-

using-o3-mini-high-across-24-robert-lavigne-axhfc/, latest access 16.06.2025.

[Le15] M. Leppanen, T. Kilamo, und T. Mikkonen, „Towards Post-Agile Development Prac-

tices through Productized Development Infrastructure“, Proceedings – 2nd International

Workshop on Rapid Continuous Software Engineering, RCoSE 2015. Institute of Elec-

trical and Electronics Engineers Inc., S. 34–40, 2015. doi: 10.1109/RCoSE.2015.14.

[LS15] T. Leal und G. Santos, „A survey on agile methods and post-agilism; [Um survey sobre

métodos ágeis e o pós-agilismo]“, CIBSE 2015 - XVIII Ibero-American Conference on

Software Engineering. Ibero-American Conference on Software Engineering, S. 53–66,

2015. [Online]. Verfügbar unter: https://www.scopus.com/inward/record.uri?eid=2-

s2.0-84936087203&partnerID=40&md5=37bda6ab195ec894cd08ec423749e2f6

[Mc13] McGinnes, S.: Barriers to Client Collaboration in Agile Offshore Information Systems

Development. In: Pooley, R., Coady, J., Schneider, C., Linger, H., Barry, C., Lang, M.

(eds) Information Systems Development. Springer, 2013, New York, NY.

https://doi.org/10.1007/978-1-4614-4951-5_48

[Mc22] McKinnon, B.: The Concept of “Post Agile” in Fully-Remote Development Teams,

2022, Compado, https://compado.com/engineering-blog/post-agile-fully-remote-devel-

opment-teams/, latest access 16.06.2025.

[MH13] Moniruzzaman, A. and Hossain, S.: Comparative Study on Agile software development

methodologies, 2013, arXiv, 1307.3356, https://arxiv.org/abs/1307.3356.

[Ni25] Nielsen, J.: Vibe Coding and Vibe Design, https://www.uxtigers.com/post/vibe-coding-

vibe-design, 2025, latest access 07.05.2025.

[NIG24] Ndou V, Ingrosso A, Di Girolamo A. Framework for Agile Transformation: Guiding

Post Agility – A Review and Outlook 141

Organizations Through Cultural, Structural, and Competency Shifts in Project Manage-

ment. Administrative Sciences. 2024; 14(11):301. https://doi.org/10.3390/ad-

msci14110301

[OFM13] Oza, N., Fagerholm, F., Münch, J.: How Does Kanban Impact Communication and Col-

laboration in Software Engineering Teams?, 2013, arXiv:1311.1323,

https://doi.org/10.48550/arXiv.1311.1323.

[Ry22] S. Rylander, „PATTERNS OF SOFTWARE CONSTRUCTION: HOW TO PREDICT-

ABLY BUILD RESULTS“, Patterns of Software Construction: How to Predictably

Build Results. Springer, 2022. doi: 10.1007/978-1-4842-7936-6.

[Sc25] Schmid, O.: Vibe Coding, Was ist Vibe Coding? - Was man wissen muss, 2025, latest

access 07.05.2025.

[SH19] L. Siddique & B- Hussein: Enablers and barriers to customer involvement in agile soft-

ware projects in the Norwegian software industry: The Supplier´s perspective. 7.

10.19255/jmpm395, 2019.

[TD18] S. Theobald und P. Diebold, „Interface problems of agile in a non-agile environment“,

in International Conference on Agile Software Development, Springer International

Publishing Cham, 2018, S. 123–130.

[Th20] S. Theobald, N. Prenner, A. Krieg, und K. Schneider, „Agile leadership and agile man-

agement on organizational level-a systematic literature review“, in Product-Focused

Software Process Improvement: 21st International Conference, PROFES 2020, Turin,

Italy, November 25–27, 2020, Proceedings 21, Springer International Publishing, 2020,

S. 20–36.

[Wo25] Wolpers, S.: Vibe Coding: Ist das agil oder nur eine Modeerscheinung?, https://berlin-

product-people.com/de/vibe-coding/, 2025, latest access 07.05.2025.

142

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 143

Resilient Governance: Securing Public Services by

Implementing Business Continuity Management Systems in

German Municipal Administrations

Rebecca Fischer1 und Karoline Busse 2

Abstract: Business Continuity Management (BCM) complements information security

management by providing reactive capabilities. Establishing a BCM is resource intensive and only

few materials are tailored to German municipalities. This paper examines the BSI 200-4 standard,

particularly its usability in the public sector. Our results indicate that the standard offers sufficient

baseline start implementation but additional support from the state government is needed. In

particular, the official supplementary materials are perceived as insufficiently usable, which might

also reflect organizational and cultural constraints within the German public administration.

Keywords: Business Continuity Management (BCM), Public Administration, Resilience, NIS 2

Directive, Quantitative Research

1 Introduction

"A town goes offline. The municipal administration of Neustadt am Rübenberge was the

target of a cyberattack." [Eh19] - with this headline, the town of 45,000 inhabitants of

Neustadt am Rübenberge in the German state of Lower Saxony came into the public

spotlight in 2019. Municipal administration in Germany is responsible for a large majority

of government services such as paying child benefits, support for refugees and asylum

seekers, child welfare protection services, and much more. Since 2019, cybercrime cases

have continued to increase in both Germany [Bu24, Ku23] and other countries [In23,

FB23]. In addition, climate change has led to an increase in extreme weather phenomena

[Se21] that raises the likelihood and frequency of local incidents such as flooding [Ah21]

and heavy rainfall [AH24], that can inhibit the availability of municipal government

services. In the case of such an emergency, it is important to quickly obtain an overview

of the affected service(s), the magnitude of their impact on residents’ daily lives, and the

options for rapid restoration. According to the new NIS 2 directive on EU level, national

and regional administrations are classified as critical infrastructure, while the applicability

to local administrations is at the discretion of the member states. Germany pledged its

federal states not to regulate local administrations [IT23b]. However, the introductory

example illustrates that the local administrations are often affected by the events described.

1 Niedersächsisches Ministerium für Inneres, Sport und Digitalisierung, Referat IT2, Schiffgraben 12, 30159

Hannover, rebecca.borges@mi.niedersachsen.de

2 Kommunale Hochschule für Verwaltung in Niedersachsen (HSVN), Institut für Digitalisierung und

Datenschutz, Wielandstraße 8, 30169 Hannover, karoline.busse@nsi-hsvn.de, https://orcid.org/0000-

0002-4484-7639

144 Rebecca Fischer und Karoline Busse

Given the approximately 11000 administrations at the local level, these attacks are not

surprising [MB24].

In cybersecurity incidents targeting critical infrastructure, human factors can be decisive.

The TRITON malware attack against a Saudi Arabian power plant in 2017 illustrates both

aspects [Ma18]. Because the relevant industrial control unit was operated in program

mode, the attackers could deploy their malware. This was likely a decision of convenience

or carelessness. Conversely, human operators noticed unsafe parameters before a

catastrophe occurred. While workers in very specialized environments such as power

plants or transportation might have a good awareness, public administrations are not

environments where staff are routinely primed for operational security [Hi18, CM19]. In

addition, the list of digital administration services that are to be implemented mandatorily

is currently at more than 900 [IT25], which leads to a large number of business processes.

In 2023, the German Federal Office of Information Security (Bundesamt für Sicherheit in

der Informationstechnik (BSI)) has issued a new public standard BSI 200-4 which covers

the topic of Business Continuity Management, is fully compatible with ISO 22301, and

focuses on small and medium organizations. In this paper, we assess awareness,

preparedness, and BCMS implementation among municipal administrations in the

German state of Lower Saxony. We align the study with BSI 200-4 and evaluate its

usability in the public sector with the following research questions (RQ).

(RQ). What is the current state of awareness, preparedness, and implementation of

Business Continuity Management (BCM) in Lower Saxony’s municipal administrations

and ministries, and what support needs do they articulate?

To answer the RQ, we conducted a quantitative survey study among municipal

administrations in the German state of Lower Saxony. Out of the total 1092 municipal and

state administration institutions in the state, we contacted 433 institutions and received

152 valid responses. The results suggest that municipalities show great interest in

implementing BCM despite not being obliged by law or other regulations to do so.

However, they need support and guidance, which they hope to get from the state ministry.

2 Related Work

Although BSI 200-4 was released in 2023, the discipline of business continuity

management is well established and practiced in countries regularly exposed to natural

hazards [CN23, KC17]. As extreme weather conditions continue to rise globally [Ou23],

it can be expected that business continuity management will become more important all

around the world in the next years.

In 2010, Warren conducted a survey about BCM implementation among the public sector

in Canada, the USA, New Zealand, and the UK. Of all respondents, 89% worked in public

administration, mostly in the field of building and facility management. Warren

discovered that many institutions from the sample had already conducted business impact

analyses which are an important step in preparation. However, 8% of participants stated

that there are no business continuity plans in case of an incident [Wa10]. As we already

Resilient Governance 145

established that Germany municipal administrations are responsible for providing the

basis of living for many people and as such should therefore prioritize business continuity.

Järveläinen conducted research in 2013 on whether the endorsement of an institution's top-

level management has a positive effect on the implementation of BCM within the

institution. They found that BCM could become part of the company's cultural values if

the management endorses it [Jä13]. In a follow-up study in 2020, Järveläinen underlined

that support and endorsement by the top-level management is essential for the success of

a business continuity management system (BCMS) [Jä20]. These results suggest that in

municipal administration, the role and attitude of the mayors plays an important part in

establishing a BCM. We investigate this further in our study (cf. Section 3).

2.1 Business Continuity Management

The BSI standard 200-4 follows a Plan-Do-Check-Act cycle of continuous improvement

(PDCA) and defines three types of BCMS: A rudimentary "reactive BCM", the

intermediate "buildup BCM", and the full "standard BCM". The foundation of a BCMS is

an institution-wide guideline that defines relevant categories of incidents, the scope, and

the responsibility of top-level management. BCM builds heavily on business processes

within an organization. In the Business Impact Analysis (BIA), critical processes are

identified and annotated with relevant metrics such as the maximum tolerable time of

disruption. Based on these results, emergency plans and recovery measures are drafted.

Note that the effort required to implement a BCMS scales with the number of business

processes an organization has. Consequently, municipal administrations face higher

workload than similarly-sized SMEs.

3 Research Design and Hypotheses

Based on our research question and previous research on the topic, we drafted three

hypotheses that informed our study.

H1: Municipal administrations with a mayor interested and informed in BCM have

already planned or implemented related measures. An organization's top management

plays an important role in implementing and maintaining a BCMS. In addition to

allocating resources, the top level must take decisions on assessing and accepting risks.

Additionally, it is of importance that the top-level management actively partakes in

exercises and tests, as they will need to push the topic over a prolonged period [BYU15].

H2: Districts and district-free cities are more advanced in BCM compared to other

municipalities. Districts and district-free cities are already obliged to implement tasks

related to disaster management3. These tasks also include risk assessment and drafting

plans for escalation and coping with natural or human-made disasters [De08]. As per the

Lower Saxon law on disaster prevention (NKatSG), the districts and district-free cities are

also required to implement emergency task forces related to disaster management.

3 see Article 1, GG, and Gesetz über den Zivilschutz und der Katastrophenhilfe des Bundes (ZSKG)

146 Rebecca Fischer und Karoline Busse

Therefore, we hypothesize that these bodies benefit from their experiences and thus are

further advanced in implementing a BCM.

H3: The municipal administration in Lower Saxony wish for more support from the

state government on the topic of BCM. The Ministry for Internal Affairs, Sport, and

Digital Transformation of Lower Saxony is already supporting the municipalities in the

field of cyber security, as they provided fully funded audits through a contractor. One of

the audit criteria was the implementation of a BCM. Other federal states in Germany show

stronger support, such as the State of Hesse which implemented a training center for state

and municipal personnel on the topic of cyber security defense4 in 2022. The federal state

of Bavaria offers similar training through their state agency for information security5, as

well as checklists, templates, and other resources [La25], and consultation services on the

topic. The state of Lower Saxony had not implemented any of these measures at the time

of our study.

4 Methodology

4.1 Instrument Development

We designed a 32-item questionnaire aligned to the stages and artefacts of BSI 200-4 (e.g.,

BC guideline, role assignment, document classification, reporting chains, exercises). Two

pilot tests (2×8 participants) informed wording, difficulty, and completion time. No items

were mandatory to preserve accuracy where implementations were absent. The full

questionnaire is provided in Appendix A with an explicit variable mapping (item →

construct → data type). Our institution does not operate an IRB/ethics board, we adhered

to the GDPR throughout design, deployment and analysis. Optional email addresses for

result notifications were stored separately from survey data.

All participants were invited through email, both through a state-wide information security

network organization (KITSIN - Kommunales IT-Sicherheitsnetzwerk Niedersachsen) and

through a contact list provided by the state office of statistics. Due to spam filtering, only

423 of the 1092 municipal administrations received the invitation. In addition, the ten state

ministries of Lower Saxony were invited to participate. All emails contained instructions

that the survey should be filled by the person who works on business continuity

management for the institution. We did not compensate the participants for their time, as

this would have created a conflict with anti-corruption regulations for public

administration workers.

4.2 Statistical Analysis

Given the ordinal nature of single-item 5-point Likert responses, we pre-specified non-

parametric procedures. Associations between binary implementations (e.g., presence of a

BC guideline) and top-management awareness (yes/no) were tested using Chi-square tests

4 Hessisches Cyberabwehrausbildungszentrum Land/Kommunen, HEECAZ L/K

5 Landesamt für Sicherheit in der Informationstechnik, LSI

Resilient Governance 147

of independence. Group differences in counts of implemented measures were analyzed

with Mann–Whitney U. For one-sample deviations from a neutral midpoint on Likert

items, we used the Wilcoxon signed-rank test; multi-group ordinal comparisons used

Kruskal–Wallis. To control the family-wise error rate across families of tests, we applied

Holm’s step-down correction and report adjusted p values for the H1 test family. We

summarize Likert responses via medians and response percentages (not means/standard

deviations) to respect the ordinal scale.

4.3 Threats To Validity

Several constructs rely on single-item Likert measures, we therefore used nonparametric

tests and report medians and response percentages. All measures are self-reported; social-

desirability and common-method bias cannot be excluded. The sample covers Lower

Saxony, therefore is generalizability to other German states or EU members limited. We

applied Holm correction for the H1 family, some subgroup counts are small, reducing

power. Recruitment combined a network list and state statistics contact list

(convenience/stratified access) and may incur non-response bias. NIS 2 Directive might

have an impact on public administration in other European countries, so future work could

yield interesting results in this field. However, in the current draft of the NIS 2

implementation in Germany, municipalities are excluded [Bu23a]. NIS 2 implementation

may change baseline awareness and support needs; we therefore recommend a follow-up

survey after national transposition.

Lower Saxony's state declared to implement BCM in 2021, including a plan to evaluate

the effectiveness and implementation of measures of Lower Saxony's Ministries and their

subordinated administrative bodies (nachgeordnete Behörden). A replication of this study

would make an interesting comparison.

5 Results

The survey was conducted between January 15 and February 26, 2024. Of the 423

institutions contacted, 152 participants completed the survey while providing valid

responses. This corresponds to a return rate of 28.1%. About eighty percent of responses

were from municipalities. Of the ten contacted ministries, nine had provided answers. 14%

did not disclose their type of institution. The responses were analyzed with the statistics

software SPSS. Results were Bonferroni-Holm-corrected for multiple testing where

applicable. We aligned our evaluation along the three hypotheses presented in Section 3.

With these hypotheses, we want to shed light especially on the role of mayors, of the

difficulties that organization size brings with it - as the services required of municipal

administration are the same regardless of size - and on the need for support when

implementing a business continuity management system.

148 Rebecca Fischer und Karoline Busse

5.1 General Findings

Of all participants, 37% stated that they know about BCM. Of these, 30% reported that

they will be responsible for the topic within their institution in the future. Of all

participants, 50% replied that their top-level management knows that they will take

responsibility for the institution's business continuity management (43% no, 7% did not

answer). The BCM guideline is present as either work-in-progress or as a completed

document in 23% of institutions. Of these, 15% of institutions plan or have already hired

external contractors to aid in the process. The guideline has been published or is currently

worked on in 23% of participants. When asked about what support they used to write the

guideline, inter-organizational collaboration, and the free official resources were checked

by 22% of participants each, another 22% stated they worked without external help, and

15% were supported by an external contractor (19% of participants did not answer).

Participants were also asked a series of questions about the standard. Median perceived

helpfulness of the BSI 200-4 standard was 3 (neutral) with 34% agreeing or strongly

agreeing that the standard document was helpful (median 3, see Figure 1). 46% of

participants agreed/strongly agreed they intend to implement their BCMS in conformity

with the standard (median = 4). Half of the participants planned to implement a reactive

BCM. 46% of participants stated that they have used or plan to use the official

supplementary material (median = 4). 46% expressed a need for more BCM materials

(median = 4), 58% for more support in general (median = 5), and 42% for more support

from the state government (median = 4).

Figure 1: Evaluation of Likert scale questions (n=152).

In addition, we asked participants from whom they need more support (Q 31 and Q32).

Approximately 61% of all participants expressed their desire for further support with key

actors being their organizational leadership level (67% agree), and municipal networks

(54%). As a closing question, participants should explain their needs precisely. We

clustered all of the 22 answers into four categories, with some answers covering more than

one category: Documents and templates, training and skills, organizational resources, and

IT reliability and standardization. Documentation and templates include templates,

Resilient Governance 149

checklists and practical documents focused on public administration (mentioned by 63%).

Training and skills references to professional training, education and skills (mentioned by

36%). Organizational resources include not only personnel but also financial resources

and responsibilities. Only 18% mentioned this category. IT reliability and standardization

is a combined need for technical infrastructure, independently from financial resources

(mentioned by 23%).

5.2 Hypothesis Tests

Regarding H1 (municipalities with a mayor interested and informed in BCM have already

planned or implemented related measures), we tested seven BCM implementation

measures against top-management awareness (Q4: "Is your top management aware of its

own important role in BCM?") (see Table 1). Those seven measures are the BC guideline

(Q10, see Appendix), the designation of BCM related roles (Q13), the classification of

documents (Q15), the establishment of an emergency task force (Q19), the definition of

reporting channels (Q26), the definition of immediate measures (Q21), and conduction of

tests and exercises (Q29) After Holm-Bonferroni correction across the seven tests, only

the association with the existence of a BC guideline and with established reporting

channels remained statistically significant; all other associations were non-significant.

Therefore, H1 is rejected.

Measure

Informed

Uninformed

χ²

p (corr.)

BC guideline (27)

6 16.487 0.007

BCM roles (61)

32 0.751 0.772

document

classification (29)

16 0.020 0.888

emergency task force

(29)

18 11 5.260 0.11

reporting channels

(29)

20 9 9.951 0.012

immediate measures

(31)

17 14 2.115 0.438

tests and exercises

(29)

12 3.471 0.248

Tab. 1: Counts and χ² test results for implemented BCM measures in administration depended on

top management awareness. Numbers behind measures tell how many participants have

implemented the measure in total. P-values have been Bonferroni-Holm corrected for multiple

testing, values marked in bold are statistically significant.

To investigate H2 (Districts and district-free cities are more advanced in BCM compared

to other municipalities), we calculated a score between 0 and 7 for each participant

regarding the implemented BCM measures. If a participant did not answer one of these

questions, the measure was counted as not implemented. To compare the administrative

150 Rebecca Fischer und Karoline Busse

bodies, we sorted them into two groups: (1) districts6 and district-free cities and (2)

municipalities, joint communities (Samtgemeinden), and ministries. The mean score of

group (1) is 3.4, (σ=2.23, median 3.5), while the other group's mean score is 1.96 (σ=1.96,

median 1). A Mann-Whitney-U test yields a significant effect on the implemented

measures for districts and district-free cities compared to other administrative bodies

(U=1053, p=0.0079). Thus, H2 is supported.

Regarding H3 (the municipalities in Lower Saxony wish for more support by the state

government on the topic of BCM), we investigate the replies to question 30, “Do you wish

for more support by the state government?”. We excluded the ministries from the replies,

as they are no municipalities. We also excluded cases with missing institution type. The

data set for this hypothesis thus contained 93 responses. The mean score for this item is

3.95, σ=1.12, median 4. Subsequently, we tested for a positive deviation from the neutral

midpoint, suggesting a clear wish for increased support from the state government. A

Wilcoxon signed-rank test shows a strong significant difference (W = 194, p < 0.001). A

Kruskal-Wallis test was conducted to examine the difference between the different local

administrative levels. The test showed no statistical significance, meaning the desire for

more support was consistently between all groups (H(5) = 2.07, p = 0.0839). Thus, H3 is

supported.

6 Discussion

The results show that municipalities in the state of Lower Saxony partially started to

implement BCMS. As municipalities strongly adhere to the principle of economic

spending, the high awareness of this optional topic is surprising. We theorize that there is

a substantial intrinsic motivation to implement BCM, likely driven by the rising number

of both cyber-attacks [Bi24, St24] and natural disasters such as river flooding [WWL24].

Further qualitative research on this aspect could shed light on the motivations on why

municipalities are motivated to implement BCM.

Our hypothesis test for H1 showed that if the top management in an administrative body

(the mayor) is aware of BCM and their own role within the management system, the

institution is more likely to have implemented a BCM guideline and formalized reporting

channels (see Section 5.2). A mandatory part of a BCM guideline is the explicit

commitment to support and work within the BCMS by the institution's top management.

Therefore, the mayor should be aware of the topic while co-creating and signing the

guideline. Similarly, when formalizing reporting channels for potential emergencies, it is

usually the top management who is in charge for a final decision whether a situation poses

a disruption, emergency, or crisis to the organization. Even though H1 is rejected after

multiplicity control, the robust correlation with the existence of a BC guideline highlights

a concrete lever: active mayoral engagement during guideline initiation and sign-off.

Therefore, we recommend a short, co-authored management commitment statement

embedded in the guideline, a standing agenda item in executive meetings to track BC

guideline enactment, and a quarterly call-tree test with written after-action notes to

6 including the Region Hannover which is a unique administrative body that is very similar to a large district

Resilient Governance 151

institutionalize reporting chains. These recommendations mirror practitioner guidance

used in Lower Saxony administrations (e.g., role concepts , exercise calendars).

Our results for H2 showed that district and district-free cities have implemented more

BCM measures on average than municipalities. This might stem from the tasks of local

disaster management, which is delegated to districts but not to municipalities. We might

observe synergies between disaster management and business continuity management, as

both frameworks use similar tools and roles. On the other hand, the scope and the assets

that are to be protected are different between BCM and disaster management, which might

lead to a better start into BCM but might not be as helpful when refining the plans and

protocols. We suggest that further research focuses on the overlaps and differences

between these management systems and the detailed benefits a pre-existing disaster

management system in a district or district-free cities can provide for a BCMS.

The hypothesis test for H3 yielded that municipalities in the state of Lower Saxony do

wish for more support by the state government on the topic of BCM. This clear wish has

been presented to the state Ministry for Internal Affairs, Sport, and Digital Transformation

of Lower Saxony and subsequently, potential measures have been discussed. As an

immediate result of this study, the state CIO financed the creation and conduction of a

two-day workshop format for municipalities on the topic of BCM which centers around

the BSI 200-4. As of writing this document, ten workshops have been conducted and over

180 people have been trained as a result. A formal evaluation of this measure is planned

for 2025. In addition, a community network for municipalities is being built at the

ministry. A project on business impact analysis blueprints for municipalities are currently

running, with different participants and stakeholders. Other measures, such as advanced

workshops on certain aspects of BCM, or special offer on personal BCM certification for

municipalities, are currently being discussed (as of July 2025). Due to early elections on

national level, Germany still does not have a national law that implements the European

NIS 2 Directive into national legislation. Even if local administrations remain out of scope,

federal legislation may raise overall BCM awareness among mayors and other top

management.

We identified a high demand for practical and usable documentation and templates. It was

repeatedly noted that the existing material "is too abstract" and "did not fit the needs of

local government". One of the participants answered: "BCM guidelines are, as it is written

[in BSI 200-4], for the private economy sector and do not align with the needs of municipal

continuity management"7. The gap between expert system design and actual user needs is

a well-known issue. Previous work shows that public servants can complete operational

tasks successfully but lack strategic internet skills [DD10]. We might have observed the

effects of a lack of skill in transferring and adapting these materials to their own

organization that results in a high desire for training and support. This may be less

problematic in groups with higher strategic internet skills. Therefore, it might be useful to

achieve a better skill set in both competences.

As stated in H3, trainings on how to implement BCM are already addressed by Ministry

for Internal Affairs, Sport, and Digital Transformation of Lower Saxony. Furthermore, the

7 All quotes were translated from German.

152 Rebecca Fischer und Karoline Busse

state ministry did not just ask what users need but instead went into development for usable

documentation with municipality administration staff. While this addresses the concrete

symptom, the larger underlying issue remains unsolved: General training on how to build

strategic Internet skills for public servants to understand how available information can be

adapted for desired goals (e.g. implementing BCMS with the given documents). The stated

need for IT reliability and standardization points out the critical importance of a reliable,

interoperable, and resilient IT infrastructure in public administration. Resilience is not

only a technical topic but arises from organizational change and the ability to adapt.

Unfortunately, public administration itself values a stable procedure in tasks above

adaptability, resulting in a strong adversity regarding change [VGK14]. Yet resilience

emerges when collectives adapt their practices to a changing environment [Ko22].

7 Summary

We present a quantitative study (n = 152) of municipalities and state ministries in Lower

Saxony, examining awareness, preparedness, and implementation status of BCMSs.

Our results indicate that Lower Saxony’s municipalities are aware of the topic and many

have already started or plan to start implementing a BCMS despite the lack of need through

laws and regulations. Districts and district-free cities are in an advantageous position here,

presumably through synergies from their expertise in disaster management. An active

participation of the mayor was identified as a key success factor for issuing guidelines and

formalizing reporting channels for potential emergencies. While the official standard BSI

200-4 is considered a solid base, we identified a lack of usability, especially regarding

document blueprints and other practice-oriented artifacts. In addition, we identified the

need for more support, especially from the state government.

As a first step, the Lower Saxony’s state CIO funded BCM training for municipal

administrations. Given the under-researched nature of German public-sector IT

governance, we recommend further research on BCM motivation, current progress, and

transferability to other states and EU members.

Acknowledgements

The authors would like to thank all participants of their study, as well as the KITSIN for

aiding in the distribution of this study and providing a platform to present the results to

the community.

This work is adapted from the first author's master thesis at the University of Applied

Administrative Sciences Lower Saxony.

Resilient Governance 153

Literaturverzeichnis

[AB00] Abel, K.; Bibel, U.: Formatierungsrichtlinien für Tagungsbände. Format-Verlag, Bonn,

2000.

[ABC01] Abraham, N.; Bibel, U.: Corleone, P.: Formatting Contributions for Proceedings. In

(Glück, H.I., Hrsg.): Proc. 7th Int. Conf. on Formatting of Workshop-Proceedings, New

York 1999. Noah & Sons, San Francisco, S. 46-53, 2001.

[An14] Anteil an Frauen in der Informatik. Statistics Worldwide, 2014.

[Az09] Azubi, L. et al.: Die Fußnote in LNI-Bänden. In (Glück, H. I., Hrsg.): Formatierung

2009. LNI 999, Format-Verlag, Bonn, S. 135-162, 2009.

[Ez10] Ezgarani, O.: The Magic Format – Your Way to Pretty Books. Noah & Sons, 2010.

[Gl09] Glück, H. I.: Formatierung leicht gemacht. Formatierungsjournal 11/09, S. 23-27, 2009.

[Wa14a] Wasser, K. et al.: Essenzen der Informatik. Verlag Formvoll, 2014.

[Wa14b] Wasser, K. et al.: Ganz neue Essenzen der Informatik im selben Jahr. Format-Verlag,

2014.

[AH24] Anhalt, Markus; Heunecke, Marlena; Niedersächsischer Landesbetrieb für

Wasserwirtschaft, Küsten- und Naturschutz (NLWKN): Winterhochwasser 2023/2024 :

Niedersächsischer Landesbetrieb für Wasserwirtschaft, Küsten- und Naturschutz

(NLWKN), 2024

[BYU15] Bakar, Zahari Abu; Yaacob, Noorulsadiqin Azbiya ; Udin, Zulkifli Mohamed: The

Effect of Business Continuity Management Factors on Organizational Performance: A

Conceptual Framework. In: International Journal of Economics and Financial Issues

Bd. 5 (2015), Nr. 1S, S. 128–134

[Bu25] Bundeskriminalamt (BKA): Polizeiliche Kriminalstatistik 2024 – Fachliche Broschüre

(IMK-Bericht). Wiesbaden: Bundeskriminalamt, 2025

[Bu17] Bundesministerium der Justiz: Gesetz zur Verbesserung des Onlinezugangs zu

Verwaltungsleistungen (Onlinezugangsgesetz - OZG), 2017.

[Bu23a] Bundesministerium des Innern und für Heimat: Entwurf eines Gesetzes zur Umsetzung

der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des

Informationssicherheitsmanagements in der Bundesverwaltung (NIS2UmsuCG), 2023.

[Bu23b] Bundesministerium des Innern und für Heimat: Online Access Act (OZG), 2023. URL

https://www.digitale-verwaltung.de/Webs/DV/EN/ozg/ozg-node.html - abgerufen am

2025-06-30

[CM19] Carr, Jerome G.; Martínez, J. Michael: Cyberattacks at the Grass Roots: American Local

Governments and the Need for High Levels of Cybersecurity. In: Public Administration

Review Bd. 79, Wiley (2019), Nr. 6, S. 895–904

[Ch23] Chiba, Yohei; Nagamatsu, Shingo: Increasing the Resilience of Japanese Companies to

Address Multi-hazard Risks. In: IDRiM Journal Bd. 13 (2023)

[DD10] van Deursen, Alexander; van Dijk, Jan: Civil Servants’ Internet Skills: Are They Ready

for E-Government? In: Wimmer, M. A.; Chappelet, J.-L.; Janssen, M.; Scholl, H. J.

(Hrsg.): Electronic Government. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010,

S. 132–143

154 Rebecca Fischer und Karoline Busse

[De08] Deutscher Landkreistag (DLT): Die Landkreise im Katastrophenschutz, 2008. URL

https://www.landkreistag.de/images/stories/publikationen/bd-76.pdf - abgerufen am

2025-04-08.

[Eh19] Ehness, Susanne: Update: Eine Stadt geht offline: Die Stadtverwaltung von Neustadt am

Rübenberge wurde Ziel eines Cyberangriffs. Die Entwicklung im Überblick (Stand

30.09.2019). URL https://www.egovernment.de/update-eine-stadt-geht-offline-a-

863498. - abgerufen am 2025-04-08

[Bi24] e.V, Bitkom: Wirtschaftsschutz 2024 – Sicherheitslage der deutschen Wirtschaft. URL

https://www.bitkom.org/Bitkom/Publikationen/Studie-Wirtschaftsschutz. - abgerufen

am 2025-04-08

[FB23] FBI: Federal Bureau of INVESTIGATION Internet Crime Report 2023 : FBI, 2023

[Hi18] Hirschl, Bernd; Aretz, Astrid; Bost, Mark; Tapia, Mariela; Gößling-Reisemann, Stefan:

Vulnerabilität und Resilienz des digitalen Stromsystems: Endbericht des Projekts

„Strom-Resilienz“. Berlin, Bremen: Institut für ökologische Wirtschaftsforschung

(IÖW) und Universität Bremen, 2018

[In23] INTERPOL: INTERPOL Annual Report 2023: INTERPOL, 2023

[IT23a] IT-Planungsrat: Beschluss 2023/39 – NIS-2-Richtlinie: Identifizierungskonzept. URL

https://www.it-planungsrat.de/fileadmin/beschluesse/2023/Beschluss2023-39_NIS-2-

Richtlinie_Identifizierungskonzept.pdf - abgerufen am 2025-06-30

[IT23b] IT-Planungsrat: Beschluss 2023/39 – NIS-2-Richtlinie: Umsetzung NIS-2-Richtlinie.

URL https://www.it-planungsrat.de/beschluss/beschluss-2023-39 - abgerufen am 2025-

06-30

[IT25] IT-Planungsrat: OZG-Informationsplattform: LeiKa-Leistungen, 2025. URL

https://informationsplattform.ozg-umsetzung.de/ - abgerufen am 2025-06-30

[Jä13] Järveläinen, Jonna: IT incidents and business impacts: Validating a framework for

continuity management in information systems. In: International Journal of Information

Management Bd. 33 (2013), S. 583–590

[Jä20] Järveläinen, Jonna: Understanding the Stakeholder Roles in Business Continuity

Management Practices – A Study in Public Sector. In: Proceedings of the 53rd Hawaii

International Conference on System Sciences, 2020

[KC17] Kato, Mio; Charoenrat, Teerawat: Business Continuity Management of Small and

Medium Sized Enterprises: Evidence from Thailand. In: International Journal of

Disaster Risk Reduction Bd. 27 (2017)

[Ko01] Kong, Wei-Chang: The implementation of electronic commerce in SMEs in Singapore.

In: E-commerce and Cultural Values, 2001.

[Ko22] Korsgaard, Henrik; Lyle, Peter; Saad-Sulonen, Joanna; Klokmose, Clemens Nylandsted;

Nouwens, Midas; Bødker, Susanne: Collectives and Their Artifact Ecologies. In: Proc.

ACM Hum.-Comput. Interact. Bd. 6. New York, NY, USA, Association for Computing

Machinery (2022), Nr. CSCW2

[Ku23] Kunz, Christopher: Cyberangriff auf Südwestfalen-IT: Mehr Kommunen betroffen,

Notbetrieb hält an: Noch immer herrscht in kommunalen Verwaltungen Südwestfalens

das Chaos. Manche Städte bangen um ihre Liquidität, anderswo werden, 2023. URL

https://www.heise.de/news/Cyberangriff-auf-Suedwestfalen-IT-Mehr-Kommunen-

betroffen-Notbetrieb-haelt-an-9532453.html. - abgerufen am 2025-08-04

Resilient Governance 155

[La25] Landesamt für Sicherheit in der Informationstechnik (LSI): IT-Notfallmanagement

(Stand 08.04.2025). URL

https://www.lsi.bayern.de/kommunen/it_notfallmanagement/index.html. - abgerufen

am 2025-08-04

[Ma18] Mandiant: TRITON Attribution: Russian Government-Owned Lab Most Likely Built

Custom Intrusion Tools for TRITON Attackers, 2018. URL

https://cloud.google.com/blog/topics/threat-intelligence/triton-attribution-russian-

government-owned-lab-most-likely-built-tools/?hl=en. - abgerufen am 2025-04-10

[MB24] Martini, Mario; Botta, Jonas: Kommunalverwaltung als Kritische Infrastruktur:

Herausforderungen bei der Umsetzung der NIS-2-Richtlinie. In: Landes- und

Kommunalverwaltung: LKV Bd. 34 (2024), Nr. 7, S. 293–299

[Mu87] Mumford, E.: Managerial expert systems and organizational change: some critical

research issues. In: Critical issues in information systems research (incoll). New York,

NY, USA : John Wiley & Sons, Inc., 1987 — ISBN 0-471-91281-6, S. 135–155

[Ou23] Our World in Data: Global damage costs from natural disasters, 1980 to 2023. URL

https://ourworldindata.org/grapher/damage-costs-from-natural-disasters , abgerufen am

2025-06-30

[Se21] Seneviratne, S.I.; Zhang, X.; Adnan, M.; Badi, W.; Dereczynski, C.; Di Luca, A.; Ghosh,

S.; Iskandar, I.; u. a.: Weather and Climate Extreme Events in a Changing Climate. In:

Masson-Delmotte, V.; Zhai, P.; Pirani, A.; Connors, S. L.; Péan, C.; Berger, S.; Caud,

N.; Chen, Y.; u. a. (Hrsg.): Climate Change 2021: The Physical Science Basis.

Contribution of Working Group I to the Sixth Assessment Report of the

Intergovernmental Panel on Climate Change. Cambridge, United Kingdom and New

York, NY, USA: Cambridge University Press, 2021, S. 1513–1766

[St24] Statista: Schäden durch Computerkriminalität in deutschen Unternehmen von 2017 bis

2024. URL https://de.statista.com/statistik/daten/studie/444719/umfrage/schaeden-

durch-computerkriminalitaet-in-deutschen-unternehmen/. - abgerufen am 2025-04-08

[VGK14] Voet, Joris; Groeneveld, Sandra; Kuipers, Ben: Talking the Talk or Walking the Walk?

The Leadership of Planned and Emergent Change in a Public Organization. In: Journal

of Change Management Bd. 14 (2014), S. 171–191

[Wa10] Warren, Clive: The role of public sector asset managers in responding to climate change:

Disaster and business continuity planning. In: Property Management Bd. 28 (2010)

[Ah21] Westdeutscher Rundfunk (WDR): Ahrtal unter Wasser - Chronik einer Katastrophe,

2021. URL https://reportage.wdr.de/chronik-ahrtal-hochwasser-katastrophe. -

abgerufen am 2025-04-08

[WWL24] Willkofer, F.; Wood, R. R.; Ludwig, R.: Assessing the impact of climate change on high

return levels of peak flows in Bavaria applying the CRCM5 large ensemble. In:

Hydrology and Earth System Sciences Bd. 28 (2024), Nr. 13, S. 2969–2989

156 Rebecca Fischer und Karoline Busse

Appendix: Questionnaire

Sehr geehrte Damen und Herren, vorab bedanke ich mich für Ihr Interesse an meiner

wissenschaftlichen Studie teilzunehmen! Hintergrund: Mit dem Kabinettsbeschluss vom

23.11.2021 hat die Niedersächsische Landesregierung den Aufbau eines strategischen und

strukturierten Notfallmanagements beschlossen. Um dieses Ziel voranzutreiben wurde ein

interministerieller Arbeitskreis gebeten, die zentralen Festlegungen im Jahr 2022

auszuarbeiten. In den überörtlichen Kommunalprüfungen der Jahre 2022 und 2023 hat der

Niedersächsische Landesrechnungshof festgestellt, dass nach wie vor ein erheblicher

Handlungsbedarf im Bereich des Notfallmanagements besteht. Nicht zuletzt verschärft die

Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14.12.2022

(NIS-2-Richtlinie) diese Thematik, indem unter anderem Maßnahmen zur

Aufrechterhaltung des Betriebs, wie ein Backup-Management und Wiederherstellung

nach einem Notfall, und Krisenmanagement gefordert werden (vgl. Art. 21 Abs. 2 c) NIS-

2-RL). Wenngleich bislang keine allgemeine Pflicht zur Implementierung eines

Notfallmanagements auf kommunaler Ebene besteht, so können Kommunen dennoch im

Rahmen ihrer kommunalen Selbstverwaltung tätig werden. Diese Umfrage dient der

Feststellung und Auswertung, ob und wie die niedersächsischen Kommunen und die

Niedersächsische Landesregierung ein Notfallmanagement / Business Continuity

Management implementiert haben. Die von Ihnen gegebenen Antworten werden

anonymisiert erhoben und lassen keine Rückschlüsse auf Ihre Behörde

zu. Die Ergebnisse werden im Rahmen einer Masterarbeit im REDACTED FOR REVIEW

genutzt.

Die Teilnahme an dieser Umfrage ist selbstverständlich freiwillig. Ich bedanke mich für

Ihre Teilnahme im Voraus!

1. Um welche Art von Verwaltungseinheit handelt es sich bei Ihrer Behörde?

Gemeinde / Samtgemeinde / Stadt / (Land-)Kreis / Kreisfreie Stadt / kommunale

Körperschaft eigener Art (z.B. Region Hannover) / Ministerium [single choice]

2. Wie viele Mitarbeitende hat Ihre Behörde / Ressort? [free text entry]

3. Weiß Ihre Institutionsleitung was Business Continuity Management (BCM)

bedeutet? Ja / Nein / Weiß nicht [single choice]

4. Ist sich Ihre Institutionsleitung bewusst, dass es sich beim Thema BCM um eine

„Chefsache“ handelt? Ja / Nein / Weiß nicht [single choice]

5. Sind Sie zukünftig für die Bearbeitung des Themas BCM zuständig oder sind es

bereits? Ja, ich bin für das Thema BCM zuständig. / Ja, ich bin aktuell für das

Thema BCM zuständig, gebe es aber in Zukunft wieder ab. / Ja, ich werde

zukünftig für das Thema BCM zuständig sein. / Nein, ich bin nicht für das Thema

BCM zuständig. [single choice]

6. Wissen Sie, was Business Continuity Management (BCM) bedeutet? Ja, ich weiß

was BCM bedeutet. / Nein, ich weiß nicht, was BCM bedeutet [shown

conditionally if Q5=Yes; single choice]

7. Welche Personalkapazitäten stehen aktuell oder künftig für die Aufgabe

Notfallmanagement zur Verfügung?(Anteil in Vollzeitäquivalenten) 0-0,25VZA

/ 0,25-0,49 VZÄ / 0,50-0,74 VZÄ / 0,75-1 VZÄ / Mehr als 1 VZÄ [single choice]

Resilient Governance 157

8. Haben Sie oder eine/n Kollege/Kollegin bereits an einer Schulung zum Thema

BCM teilgenommen? Ja / Nein [single choice]

9. Haben Sie bereits ein externes Unternehmen mit der Unterstützung im BCM

beauftragt oder haben dies vor? Ja / Nein [single choice]

10. Besitzt Ihre Behörde bereits eine Leitlinie zum Notfallmanagement oder

erarbeitet aktuell eine? Ja / Nein [single choice]

11. Haben Sie Hilfsmittel für die Erstellung der Leitlinie genutzt? Ja / Nein [shown

conditionally if Q10=Yes; single choice]

12. Wie einfach war bzw. wäre es für Sie...

a. die Motivation efür eine Leitlinie zu formulieren?

b. die Ziele für ihr BCMS festzulegen?

c. den abzusichernden Zeitraum festzulegen?

d. den Geltungsbereich des BCMS festzulegen? Sehr schwer / schwierig /

weder noch / einfach / sehr einfach [5-point Likert scale]

13. Welche dieser Rollen haben bzw. werden Sie für das BCMS in Ihrer Behörde

übernehmen? BC-Beauftragter / BC-Koordinierende / BC-Gremium / BC-

Vorsorgeteams / Ich werde keine der Rollen aus dem BSI-Standard 200-4

übernehmen. [multiple choice]

14. Für welche Stufe haben Sie sich bzw. würden Sie sich in Ihrer Behörde

entscheiden? Reaktiv-BCMS / Aufbau-BCMS / Standard-BCMS [single choice]

15. Ist in Ihrer Behörde bereits eine Kennzeichnung für Dokumente vorhanden?

(Eine Dokumentenkennzeichnung dient der gezielten Steuerung, Aufbereitung

und Einordnung. Die Kennzeichnungen dienen der Dokumentenlenkung. Sie

geben einen schnellen Überblick darüber, was im Dokument geregelt wird und

wie mit dem Dokument und dessen Inhalt umzugehen ist. Beispiel: vertraulich,

intern, VS-Nur für den Dienstgebrauch o.ä.) Ja / Nein [single choice]

16. Warum haben bzw. würden Sie sich für diese Stufe entscheiden? [conditionally

shown if Q14=Yes; free text entry]

17. Welche Kennzeichnung verwenden Sie bereits für Ihre Dokumente? eindeutiger

Titel / eindeutige Versionsnummer (falls relevant) / Dokumentenart / Autor,

Autorin / Freigabedatum und -person / Datum der nächsten geplanten

Überarbeitung (für Dokumente, die Änderungen unterliegen können) /

Geltungsbereich des Dokuments (sofern für die Dokumentenart erforderlich) /

Klassifizierung / Zielgruppe / Ablage / Aufbewahrungszeitraum (falls

erforderlich)/Änderungshistorie / Sonstiges / Freitext [conditionally shown if

Q15=Yes; multiple choice and free text entry]

18. Gab es in Ihrer Behörde bereits einen Notfall oder eine Krise? (Beides ist auch

möglich) Wir hatten bereits einen Notfall in unserer Behörde. / Wir hatten bereits

eine Krise in unserer Behörde. / Beides / Es gab bisher weder einen Notfall noch

eine Krise. [multiple choice unless the last option was selected]

19. Verfügt ihre Behörde über einen (geschulten) Stab, der in Notfällen als zentrales

Führungsgremium agiert? Ja, wir haben einen Stab. / Nein, wir haben keinen

Stab. [single choice]

20. Gibt es in Ihrer Behörde festgelegte Meldewege, falls ein Schadensereignis

auftritt? Ja, wir haben festgelegte Meldewege. / Nein, wir haben keine

festgelegten Meldewege. [single choice]

158 Rebecca Fischer und Karoline Busse

21. Sind in Ihrer Behörde Sofortmaßnahmen bei Schadensereignissen definiert?

(Hierbei handelt es sich um entsprechende Anweisungen und konkrete Aufgaben.

Sofortmaßnahmen sind z. B. Maßnahmen zur Räumung von Gebäuden oder

Handlungsanweisungen bei Wassereinbruch.) Ja, wir haben Sofortmaßnahmen

definiert und dokumentiert. / Ja, wir haben Sofortmaßnahmen für einige

Schadensereignisse definiert und dokumentiert. / Nein, wir haben keine

Sofortmaßnahmen definiert und dokumentiert. [single choice]

22. Haben Sie nach einer Krise oder einem Notfall eine strukturierte Analyse der

Bewältigung durchgeführt? Ja, wir haben den Notfall/die Krise aufgearbeitet. /

Nein, wir befassen uns nach Abschluss nicht mehr damit. [single choice]

23. Haben Sie zur Bewältigung des Notfalls / der Krise eine Besondere

Aufbauorganisation (BAO) eingerichtet? (Eine BAO ist eine zeitlich begrenzte

Organisationsform, die in außergewöhnlichen Situationen schnell und

angemessen reagieren kann.) Ja, wir haben das Problem mit einer BAO gelöst. /

Nein, wir haben das Problem in der Linie gelöst. [conditional question shown if

(18)=Yes or both, single choice]

24. Welche Kernthemen sind in Ihrem Stab besetzt? IT / Personal /

Gebäudeverwaltung / Kommunikation / Sonstige (Freitext) [conditionally shown

if Q19=Yes; multiple choice and free text entry]

25. Welche Kernthemen würden Sie in Ihrem Stab besetzen? Personal / IT /

Kommunikation / Recht / Sicherheit / Weitere [conditionally shown if Q19=No;

multiple choice]

26. Sind alle Beteiligten der Meldewege ausreichend sensibilisiert bzw. geschult? Ja

/ Nein / Wir arbeiten aktuell an der Sensibilisierung/Schulung. [conditionally

shown if Q20=Yes; single choice]

27. Geschäftsprozesse in Ihrer Behörde: Wir haben bereits… eine vollständige

Geschäftsprozesslandkarte. / einige Geschäftsprozesse erfasst und dokumentiert.

/ keine Geschäftsprozesse erfasst und dokumentiert. [single choice]

28. Geschäftsprozesse in Ihrer Behörde: Ich bin vertraut mit dem Vorgehen...

a. des Business-Impact-Analyse-Vorfilters.

b. einer Business-Impact-Analyse.

c. eines Soll-Ist-Vergleichs.

d. einer (BCM-)Risikoanalyse.

e. der Erstellung von Geschäftsfortführungsplänen.

f. der Erstellung von Wiederanlauf- und Wiederherstellungsplänen. [5-

point Likert scale]

29. Wir haben in unserer Behörde bereits folgende Übungen und Tests durchgeführt:

Planbesprechung / Stabsübung / Stabsrahmenübung / Alarmierungsübung /

Funktionstest / Wir haben keine der oben genannten Übungen/Tests bisher

durchgeführt. [multiple choice]

30. Fast geschafft! Bitte beantworten Sie noch folgende Fragen:

a. Den BSI-Standard 200-4 empfand ich als hilfreich.

b. Ich habe oder werde den BSI-Standard 200-4 für die Implementierung

eines BCMS nutzen.

c. Ich habe die Hilfsmittel des BSI-Standards 200-4 genutzt oder plane

diese zu nutzen.

d. Ich wünsche mir mehr Hilfsmittel zum Thema BCM.

Resilient Governance 159

e. Ich wünsche mir mehr Unterstützung von der niedersächsischen

Landesregierung zum Thema BCM.

f. Ich fühle mich gut vorbereitet, ein BCM in einer Behörde zu

implementieren. [5-point Likert scale and abstention]

31. Ich wünsche mir mehr Unterstützung von... meiner Leitung. / kommunalen

Netzwerken. / externen Dienstleistern. / meinen Kollegen / Kolleginnen. / dem

BSI. / Ich wünsche mir keine Unterstützung. [multiple choice]

32. Falls Sie sich mehr Hilfsmittel für das Thema BCM wünschen, welche wären

das? (Dies könnten zum Beispiel mehr Schulungen oder eine „To-Do-Liste“ sein.

Bitte beschreiben Sie dies so konkret, wie möglich.) [free text entry]

160

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 161

Zwischen Stabilität und Anpassungsfähigkeit ‒ Entwick-

lung und Anwendung eines Reifegradmodells für Lean-

Adaptive Project Portfoliomanagement

Claus Hüsselmann1 und Janek Hergenröder2

Abstract: In diesem Beitrag wird ein Reifegradmodell für Lean-Adaptive Projektportfoliomanage-

ment vorgestellt und am Beispiel einer Fluggesellschaft angewendet. Nach einer Einführung in die

zentralen Begriffe des Multiprojektmanagements und das Referenzmodell Lean-Adaptive Project

Portfolio Management (LAUP²) wird ein systematisches Vorgehen zur Entwicklung von Reifegrad-

modellen abgeleitet. Das resultierende Modell umfasst die drei Dimensionen Prozesse, Rollen und

Prinzipien und dient der strukturierten Bewertung der Reife von Projektportfoliomanagement-Sys-

temen. Eine exemplarische Anwendung des Reifegradmodells zeigt, wie das Modell zur Identifika-

tion von Optimierungspotenzialen beitragen und darauf aufbauend konkrete Handlungsempfehlun-

gen bieten kann. Abschließend erfolgt eine Evaluation des Modells. Die Ergebnisse unterstreichen

den Mehrwert des entwickelten Reifegradmodells für die praxisnahe Weiterentwicklung von Lean-

Adaptive Projektportfoliomanagement in Organisationen.

Keywords: Projektportfoliomanagement (PPM), Lean-Adaptive PPM, Reifegradmodell, Fallstudie

1 Hintergrund und Zielsetzung

Unternehmen werden aktuell mit unterschiedlichen globalen Trends und Herausforderun-

gen konfrontiert, wie z.B. von Krisen und der Digitalisierung. Infolgedessen steigen die

Anforderungen an die Wandlungsfähigkeit der Unternehmen, sodass auch deutlich mehr

Dynamik und Reaktionsgeschwindigkeit im Projektmanagement gefordert sind [Fr23].

VUKA (volatil, unsicher, komplex, ambig) beschreibt diese Herausforderungen und er-

schwert auch die übergeordnete Koordination, Planung und Steuerung der Projektland-

schaften [Hü21]. Klassisches, stabilitätsorientiertes Projektportfoliomanagement (PPM)

genügt diesen Anforderungen häufig nicht mehr. Die Integration von Prinzipien der Agi-

lität und des Lean Management verspricht eine höhere Anpassungsfähigkeit und Zielori-

entierung [KG22, Hü21]. Allerdings fehlen bislang spezifische Reifegradmodelle, die die-

sen Ansatz systematisch unterstützen. Das Lean-Adaptive Unified Project Portfolio Ma-

nagement-Referenzmodell (LAUP²) bildet die inhaltliche Grundlage für die vorliegende

Gestaltung eines Reifegradmodells. Das Modell vereint ein Prozess-, Ziel- und Rollenmo-

dell für das PPM mit der Lean-Adaptive Philosophie [Hü24]. Dieser Beitrag beschreibt

die Entwicklung und Evaluation eines spezifischen Reifegradmodells für LAUP². Die

zentrale Forschungsfrage lautete:

Wie kann ein spezifisches Reifegradmodell die praktische Einführung und Weiter-

entwicklung von Lean-Adaptive PPM in Organisationen unterstützen?

1 TH Mittelhessen, FB Wirtschaftsingenieurwesen, Wilhelm-Leuschner-Str. 13, 61169 Friedberg (Hessen),

claus.huesselmann@wi.thm.de

2 Campana & Schott, Gräfstraße 99, 60487 Frankfurt am Main, janek.hergenroeder@campana-schott.com

162 Claus Hüsselmann und Janek Hergenröder

Der vorliegende Beitrag beschreibt die Entwicklung und Anwendung eines Reifegradmo-

dells für Lean-Adaptive Projektportfoliomanagement auf der Grundlage des LAUP²-Re-

ferenzmodells am Beispiel eines mittelständischen Unternehmens. Dazu gehören

1. Entwicklung einer LAUP²-spezifischen Reifegradmodell-Architektur

2. Priorisierung der Prozesse, Rollen und Fähigkeiten

3. Anwendung des entwickelten Reifegradmodells

4. Evaluation und Optimierung des entwickelten Reifegradmodells

Um praktisches Feedback für das LAUP²-Framework zu erhalten und das entstehende

Reifegradmodell anzuwenden, konnte die Fluggesellschaft SunExpress als Kooperati-

onspartner gewonnen werden. SunExpress ist ein 1989 gegründetes Unternehmen und hat

mehr als 3.500 Mitarbeiter (Stand 2024) [Su24].

Das Projektportfolio von SunExpress umfasst ca. 30 laufende Infrastruktur-, Organisati-

ons- und insbesondere IT-Projekte mit einem mittleren Budget i.H.v. ca. 2 Mio€ (Median

ca. 400 k€) ‒ und hat damit durchaus eine durchschnittliche Charakteristik [KG22]. Das

Unternehmen betreibt bereits ein professionelles PPM, verfolgt jedoch den Wunsch, das

hauseigene Project Management Office (PMO) weiterzuentwickeln und flexibler zu ge-

stalten.

2 Grundlagen und Begriffsdefinitionen

2.1 Multiprojektmanagement und Projektportfoliomanagement

Für die Umsetzung von Veränderungs- und Neuerungsvorhaben werden Projekte durch-

geführt und bilden somit einen fundamentalen Bestandteil unternehmerischen Handelns

[HAN19, St15]. Laut einer aktuellen Studie der deutschen Gesellschaft für Projektma-

nagement (GPM) wurden im Jahr 2022 knapp 34,5% der Wertschöpfung durch Projekte

erbracht [GP23]. Multiprojektmanagement (MPM) befasst sich mit der gleichzeitigen

Steuerung mehrerer Projekte und der Koordination von Abhängigkeiten, Synergien und

Ressourcenkonflikten [HAN19, Se11, Fr23, St15]. Das Projektportfoliomanagement

(PPM) ist eine Form des MPM und beschreibt die permanente Planung, Priorisierung,

Steuerung und Überwachung der Projektlandschaft eines Unternehmens zur strategischen

Zielerreichung [Di13, Pr17a, Ax19, Se11, Ri19, LW19, De20, HAN19, Pr17b].

2.2 Lean-Adaptive Project Portfolio Management

Das LAUP²-Referenzmodell kombiniert Elemente des klassischen PPM – Prozess-, Ziel-

und Rollenmodell – mit den Prinzipien einer Lean-Adaptive Philosophie. Ziel ist es, Un-

ternehmen ein Framework zur flexibleren Gestaltung ihrer Projektlandschaften und ihres

PPM-Systems zu bieten. Die Integration von Lean- und agilen Prinzipien steht dabei im

Fokus [HE24]. Die Elemente des LAUP2 als Managementsystems für PPM beantworten

ganzheitlich die Frage „Was macht wer wie und womit?“. Die Berücksichtigung empirisch

belegter Erfolgsfaktoren führt dabei zu einem Prinzipienkanon, der Richtungsweisung für

Lean-Adaptive PPM-Reifegrad 163

die zielgerichtete, wertorientierte Ausgestaltung des PPM im Unternehmen gibt [Hü24].3

Die Lean-Adaptive Philosophie vereint die Auffassung von Lean, Prozesse und Methoden

möglichst verschwendungsarm zu gestalten, mit einer adaptiven Denkweise, die durch

eine flexible und situationsangepasste Vorgehensweise geprägt ist. Grundsätze und Prak-

tiken werden dabei in absteigender Verbindlichkeit für die Umsetzung der Philosophie

genutzt. Die Grundsätze des LAUP²-Referenzmodells bestehen aus dem zentralen Para-

digma Vermeidung von Verschwendung und sieben weiteren Kernprinzipien:

- Strategieorientierung – Warum wird ein Projekt durchgeführt?

- Kundenorientierung – Wer ist der jeweilige (Prozess-)Kunde?

- Prozessorientierung – Wie wird die Leistung im PPM erbracht?

- Engpassorientierung – Was begrenzt den Durchsatz von Projekten?

- Adaptivität – Welchen PM/PPM-Ansatz erfordert der (aktuelle) Kontext?

- Minimalität – Wie viel ist wirklich nötig zur Erreichung von Mehrwert im PPM?

- Menschenorientierung – Wie ist das Engagement der Mitwirkenden zu erreichen?

Im LAUP2-Modell werden zudem Praktiken durch operative Handlungsprinzipien sowie

eine Vielzahl von Methoden und konkreten Tools definiert, die es ermöglichen die ge-

nannten Grundsätze operativ anwendbar zu machen. Dazu gehören Elemente wie das Agi-

lometer, das PPM-Spaghetti-Diagramm, Projekt-Kanban oder die Scored Shortest Project

Fit-Nutzenfunktion (SSPF) [Hü24].

2.3 Reifegradmodell

Ein Reifegradmodell umfasst die kontextuell methodische Definition von Reifegraden

(RG) für eine betriebswirtschaftliche Domäne und beschreibt dadurch einen antizipierten,

gewünschten oder typischen Entwicklungspfad der Elemente dieser Domäne in aufeinan-

der folgenden, diskreten Rangstufen, beginnend in einem Anfangsstadium bis hin zur voll-

kommenen Reife [BKP09, MRW09, Br05, SG10, FMG02, Kü13]. Da im vorliegenden

Kontext ein kontinuierlicher Verbesserungsprozess angestrebt wird, ist die Reifegradbe-

stimmung als iterativer Prozess (Phasen) zu etablieren. Indem ein Ist- und ein Soll-Zustand

ermittelt wird, können Verbesserungsmaßnahmen für die Überwindung der Differenz de-

finiert werden [Hö12].

3 Entwicklung eines Reifegradmodells für Lean-Adaptive PPM

3.1 Vorgehensmodell

Ein Kritikpunkt an RG-Modellen ist eine nicht immer nachvollziehbare Entwicklung des

Modells [BKP09]. Grundlage für die Entwicklung des LAUP2-RG-Modells bildet daher

ein aus Becker et al. (2009) und de Bruin et al. (2005) abgeleitetes Vorgehensmodell

[BKP09, Br05]. In einem ersten Schritt wurde eine Problemdefinition durchgeführt: Ziel

ist eine Standortbestimmung und Verbesserung des PPM (= Domäne) durch die Anwen-

3 Eine detaillierte Beschreibung findet sich ebd.

164 Claus Hüsselmann und Janek Hergenröder

dung bzw. Einführung des LAUP²-Referenzmodells sowie Aufzeigen eines Entwicklungs-

pfades. Die Zielgruppe sind Unternehmen, die PPM einführen oder ihr vorhandenes PPM

‒ nicht zuletzt im Sinne einer Prinzipienorientierung ‒ verbessern wollen. Diese Model-

lanforderungen bilden das Zielsystem, anhand dessen das Modell im späteren Verlauf

auch evaluiert werden kann.

Folgende Anforderungen an das Modell wurden sich im vorliegenden Kontext abgeleitet:

- A1: Das Reifegradmodell soll eine Bewertung der aktuellen PPM-Reife (in Bezug

zum LAUP²-Referenzmodell) ermöglichen.

- A2: Das Reifegradmodell soll einen Entwicklungspfad vorgeben.

- A3: Das Reifegradmodell soll die Weiterentwicklung ausgewählter Fähigkeiten im

Sinne eines unternehmensspezifischen Tailorings unterstützen.

- A4: Das Reifegradmodell soll das Voranschreiten entlang des Entwicklungspfads

durch konkrete Maßnahmen unterstützen.

- A5: Die Anwendung des Reifegradmodells sollte einfach sein und durch eine

„schlanke“ Bewertung ermöglicht werden.

- A6: Das Reifegradmodell soll die Inhalte des LAUP²-Frameworks und der damit

verbundenen Prozesse, Rollen und Prinzipien abdecken.

Aus der Definition der Anforderung ergibt sich damit ein Zielsystem bestehend aus sechs

Anforderungen. Diese dienen sowohl der Auswertung des Vergleichs bestehender Reife-

gradmodelle als auch schlussendlich der Evaluation des entwickelten Modells.

Die zweite Phase war der Vergleich bestehender Reifegradmodelle. Dafür wurden ausge-

wählte RG-Modelle analysiert, wobei insbesondere die Modellarchitektur und -inhalte und

Erhebungsmethode betrachtet wurden. Die Modelle wurden anschließend hinsichtlich ih-

rer Eignung anhand der zuvor formulierten Modellanforderungen ausgewertet. Aufbauend

darauf wurde eine Strategie für die weitere Entwicklung des RG-Modells ausgewählt.

Die dritte Phase bildete die RG-Modellgestaltung, die sich mit der Definition der Modell-

dimensionen und Modellinhalten befasst. Anschließend folgte die Formulierung von Rei-

fegraden für die jeweilige Dimension und die Festlegung auf ein Erhebungsverfahren. Die

Modellinhalte sind grundsätzlich bereits durch das LAUP²-Referenzmodell festgelegt. In-

nerhalb dieser Phase musste der Inhalt aus dem Referenzmodell den Dimensionen und

Reifegraden zugeordnet werden.

Anschließend folgte die Anwendung des entwickelten Modells als vierte Phase. Durch die

Anwendung sollte festgestellt werden, ob die Modellinhalte und Erhebungsmethode die

formulierten Anforderungen erfüllen. Dafür wurde das Feedback der Anwender eingeholt.

Abschließend wurde durch die Evaluation und Optimierung in Phase fünf das Feedback

und die Erfahrung aus der pilothaften Anwendung durch SunExpress dazu genutzt, ggf.

auftretende Schwachstellen zu identifizieren und das Modell weiterzuentwickeln.

3.2 Eignung bestehender Reifegradmodelle

Als Basis wurden folgende verfügbare RG-Modelle identifiziert [Al14] und anschließend

durch die definierten Anforderungen hinsichtlich ihrer Eignung analysiert:

Lean-Adaptive PPM-Reifegrad 165

- Projektmanagement (insb. Projektportfoliomanagement): Capability Maturity

Model Integrated for Development (CMMI), Organizational Project Management

Maturity Model (OPM3), Portfolio, Programme and Project Management Maturity

Model (P3M3) [CM10, HK12, Pr03, LR08, Bu23, PM24]

- Prinzipienorientierung: Agile Adoption Framework (AAF), Lean Capability Model

(LCM) [OD13, SAB07, Jø07]

- Qualitätsmanagement: European Foundation for Quality Management-Ansatz

(EFQM) [EF20, So18, Br21]

Die Modelle wurden hinsichtlich ihrer strukturellen und inhaltlichen Eignung analytisch

durch die Autoren bewertet: „○“ ‒ die Anforderung wird nicht oder nur minimal erfüllt,

„◑“ ‒ die Anforderung wird teilweise erfüllt, jedoch sind noch erhebliche Anpassungen

notwendig, „●“ ‒ die Anforderung wird voll erfüllt, es sind nur minimale Anpassungen

notwendig (siehe Abbildung 1).

Abbildung 1: Ergebnis des Vergleichs bestehender Reifegradmodelle

Insgesamt kann festgehalten werden, dass keines der betrachteten Modelle alle Anforde-

rungen erfüllt. Dies liegt allerdings in der Natur der Sache, da die Anforderungen zum

Teil LAUP²-spezifische Inhalte fordern.

3.3 Festlegung der Entwicklungsstrategie

Eine komplette Neuentwicklung erschien nicht notwendig, da bisherige Ansätze genügend

Überschneidungspunkte zu den Anforderungen an das zu entwickelndes Modell inneha-

ben. Die Weiterentwicklung eines einzelnen RG-Modells konnte ebenfalls ausgeschlossen

werden, da keines der betrachteten Modelle sowohl die Prozesse und Rollen des PPM als

auch prinzipienspezifische Merkmale ausreichend abdeckt. Die Kombination mehrerer

Modelle erschien aufgrund der signifikanten Unterschiede innerhalb der Modelle als zu

aufwendig.

Anhand der Auswertung wurde die Übertragung von Struktur und Inhalten als Entwick-

Index Bezeichnung

A1 Bewertung der PPM-Reife

A2 Entwicklungspfad

A3 Tailoring

A4 Ableitung von Maßnahmen

A5 Einfache Anwendung

A6 Inhalte

A6.1 Prozesse

A6.2 Rollen

A6.3 Grundsätze

Anforderungen

CMMI

OPM3

P3M3

AAF

LCM

EFQM

166 Claus Hüsselmann und Janek Hergenröder

lungsstrategie festgelegt, da Aspekte und Inhalte unterschiedlicher Modelle erfolgsver-

sprechend für die Entwicklung des Reifegradmodells für das LAUP²-Referenzmodell er-

scheinen. In der Literatur existiert kein konkreter methodischer Ansatz für die Durchfüh-

rung dieser Entwicklungsstrategie [BKP09]. Daher sind die Erkenntnisse aus der Analyse

bestehender Reifegradmodelle an der Stelle in der Modellentwicklung eingeflossen, bei

der ein hohes Maß an Übereinstimmung gemäß den formulierten Anforderungen festge-

stellt werden konnte.

4 Reifegradmodellgestaltung für das Lean Adaptive PPM

Die Bewertung der Reife des PPM auf der Basis des LAUP²-Frameworks stellt das Ergeb-

nis der Entwicklung des Reifegradmodells dar. Die Reife des PPM setzt sich aus den drei

Dimensionen Prozesse, Rollen und Prinzipien zusammen. Die Dimensionen werden durch

die jeweiligen Bestandteile aus dem LAUP²-Referenzmodell mit Inhalt befüllt. Für die

Prozesse heißt das konkret, dass die einzelnen Geschäftsprozesse durch das Reifegradmo-

dell bewertet werden. Die Rollen werden gemäß Rollenkanon in das Modell übernommen.

Für die Dimension der Prinzipien werden die Kernprinzipien als Bewertungsgrundlage

verwendet. Die Handlungsprinzipien, Praktiken und Methoden werden in das Reifever-

ständnis der Kernprinzipien in Form von sog. Ankerelementen integriert.

4.1 Definition des Reifeverständnis

Die Bestimmung der Reifegrade erfolgte Top-Down, indem zunächst ‒ wie in vielen Mo-

dell üblich [Al14] ‒ fünf Reifegrade semantisch differenziert definiert (Abbildung 2) und

anschließend spezifische Merkmalsausprägungen zugeordnet wurden [Br05]. Für die

Merkmalsausprägungen folgt das LAUP²-RG-Modell dem Grundsatz des CMMI, indem

für jedes Betrachtungsobjekt generische und spezifische Ziele definiert werden. Hierbei

wurden für jede der Dimensionen generische Beschreibungen erstellt, die die Reifegrad-

dimensionen der Domäne allgemein beschreiben sowie Ankerelemente, die dazu dienen,

den Reifegrad eines Bewertungsobjekts spezifisch zu definieren. Die Ankerelemente sol-

len darüber hinaus die Anwendung des Modells erleichtern, da repräsentative Beispiele

für Methoden und Praktiken eine schnellere Einordnung ermöglichen. Durch die An-

kerelemente wird der durch die Reifegradstufen vorgegebene Entwicklungspfad mit kon-

kreten Beispielen versehen.

RG Prozesse Rollen Prinzipien

1 Initial Initial (>10%) Initial

2 Wiederholbar Definiert (>30%) Konzeptionell

3 Definiert Ausgeführt (>50%) Integriert

4 Quantitativ geführt Fortgeschritten (>70%) Systematisch

5 Optimiert Optimiert (>90%) Ganzheitlich

Abbildung 2: Reifegradstufen der Dimensionen (Details siehe Anhang)

Lean-Adaptive PPM-Reifegrad 167

Die Reifegrade für die Prozess-Reife wurden in Anlehnung an CMMI und P3M3 definiert

[LR08, CM10]. Für die Ableitung von Ankerelementen wurden hier u.a. die typischen

Erfolgsfaktoren der einzelnen Prozesse genutzt. Daneben dienten die PPM-Wertströme

sowie die Praktiken für Lean-Adaptive PMM als Grundlage für die Definition der An-

kerelemente [Hü24, LR08, CM10]. Nachfolgend wird das Vorgehen exemplarisch am

Prozess PPM System Strategy Determination veranschaulicht:4

1 ‒ Initial: Die Ziele und die Strategie von PPM basieren auf einem „Bauchgefühl“ des

Managements. Häufig wechselnde Ziele und Leistungsumfänge.

2 ‒ Wiederholbar: Portfolioziele und -strategie werden definiert und sind abgeleitet aus

der Unternehmensstrategie. Leistungsumfang ist teilweise unklar und unterschiedlich.

3 ‒ Definiert: Die Ziele und die Strategie des Portfolios sind definiert, leiten sich von der

Unternehmensstrategie ab und ändern sich nicht innerhalb eines bestimmten Zeitraums.

Die Kommunikation von Zielen, Strategie und Umfang ist transparent und verständlich.

Teilportfolios können auf der Grundlage strategischer Entscheidungen gebildet werden

(z. B. Strategic Buckets für F&E).

4 – Quantitativ geführt: Überprüfung der Wirksamkeit des PPM-Systems → Benefit Re-

vision. Etablierung eines umfassenden Instrumentariums zur Umsetzung der Unterneh-

mensvision und -strategie in ein kohärentes Set von Leistungsmessungsfaktoren (z.B.

PPM spezifische Balanced Scorecard).

5 ‒ Optimiert: Das PPM-System wird nach einem bestimmten Zeitraum, z.B. einem

Jahr, evaluiert. PPM-Ziele und -Strategie können bei Bedarf angepasst werden (je nach

Leistung oder neuen Anforderungen).

Für die Bestimmung der Rollen-Reife konnte kein geeignetes Basis-RG-Modell identifi-

ziert werden. Daher handelt es sich bei der Definition der Reifegradstufen der Rollen um

eine Neuentwicklung, basierend auf den bereits vorgestellten Reifegraden der Prozess-

Reife und dem LAUP²-Referenzmodell. Die Ableitung von Ankerelementen war für die

Rollen nicht sinnvoll möglich, da spezifische Merkmale für Rollen nur schwer identifiziert

werden können. Als Alternative wurde ein Erfüllungsgrad der Rolle [%] bestimmt, der bei

der Einschätzung des Reifegrades, neben der generischen Beschreibung, eine Hilfestel-

lung für die Bewertung gibt.

Die Reifegrade der Dimension Prinzipien wurden in Anlehnung an das AAF sowie den

bisher vorgestellten Reifegraden definiert [SAB07]. Die Bestimmung von Ankerelemen-

ten erfolgt auf Basis der Beschreibungen der Prinzipien, Handlungsprinzipien und Prakti-

ken [Hü24]. Beispielhaft werden die abgeleiteten Ankerelemente für das Prinzip Engpass-

orientierung aufgezeigt:

1 ‒ Initial: Der Engpass wird erst sichtbar, wenn er auftritt → reaktive Maßnahmen.

Keine oder wenig vorausschauende Planung, z.B. der gleichzeitig benötigten Ressour-

cen.

4 Die Ankerelemente für alle anderen Elemente des Modells sind in [HH25] verfügbar.

168 Claus Hüsselmann und Janek Hergenröder

2 ‒ Konzeptionell: Die Engpassorientierung wird auf Projektebene umgesetzt. Die Pro-

jekte sind für die Verwaltung ihres eigenen Arbeitsablaufs verantwortlich.

3 ‒ Integriert: Engpässe werden auf Portfolio-Ebene untersucht. Vermeidung von Mul-

titasking, z.B. Projekte pro Mitarbeiter. Einsatz von Pull-Prinzipien, wie Kanban, am

Engpass.

4 ‒ Systematisch: WiP-Grenze (Work-in-Progress) wird definiert und visualisiert, z.B.

Begrenzung von gleichzeitig durchgeführten Projekten. Gleichzeitig durchgeführte Pro-

jekte werden auf mögliche Engpässe überwacht, z.B. Status-Dashboards, Flow-Charts.

5 ‒ Ganzheitlich: Einhaltung der WiP-Grenze als Kontrollparameter für die Leistung des

PPM. Reviews und Lessons Learned werden genutzt, um weitere Engpässe zu identifi-

zieren und ihren Durchsatz zu maximieren. Engpässe können durch die verwendeten

Methoden schnell identifiziert werden.

4.2 PPM-Reife (in Bezug zum LAUP²-Referenzmodell)

Die Gesamtbewertung der Reife erfolgt durch eine Zusammenführung der Ergebnisse aus

den Prozessen, Rollen und Prinzipien und wird mit einem Prozentwert (Erfüllungsgrad

„EPPM“) angegeben. Damit folgt die Reifegradsystematik grundlegend der Vorgehens-

weise des OPM3 und dessen Darstellung im Kontinuum. [LR08]. Inspiriert ist diese Dar-

stellung durch das EFQM, wo durch die Addition der Ergebnisse verschiedener Dimensi-

onen ein Gesamtresultat ermittelt wird [EF20]. Speziell um die Anforderungen A1 (Be-

wertung) und A2 (Entwicklungspfad) zu erfüllen, werden für die Erreichung bestimmter

Prozentbereiche in Abstimmung mit den SunExpress-Experten „Reife-Phasen“ definiert:

Phase 0 ‒ No PPM: PPM wird nicht oder nur in minimalem Ausmaß durchgeführt (0–

10%).

Phase 1 ‒ Baseline PPM: Die grundlegenden Prozesse für PPM sind in der Organisation

eingeführt. Bisher werden die Prozesse aber nur rudimentär und ohne die Anwendung

von Prinzipien durchgeführt (11–35%).

Phase 2 ‒ Enhanced PPM: PPM ist fest in der Organisation verankert und kann bereits

messbare Erfolge erzielen. Es bestehen erste Bestrebungen das PPM-System hinsichtlich

einer Lean-Adaptive Philosophie auszubauen (36–55%).

Phase 3 ‒ Sustainable PPM: Das PPM ist in der Organisation gut etabliert und trägt

nachhaltig zum Unternehmenserfolg bei. Portfolioprozesse und Rollen sind definiert und

umfassend implementiert. Das PPM-System ist bereits nach einer schlanken, adaptiven

Philosophie gestaltet und die Grundprinzipien sind bekannt (56–75%).

Phase 4 ‒ Principle based PPM: PPM wird in seiner Gesamtheit durchgeführt und hat

einen entscheidenden Einfluss auf den Unternehmenserfolg. Die PPM-Prozesse und

-Rollen sind vollständig etabliert und werden kontinuierlich verbessert. Die Lean-Adap-

tive Philosophie wird durch bewährte Praktiken umgesetzt, die umfassend und ganzheit-

lich im gesamten PPM-System angewendet werden (76–90%).

Phase 5 ‒ PPM Excellence: PPM wird vollumfänglich in der Organisation durchgeführt,

Lean-Adaptive PPM-Reifegrad 169

wodurch das PPM einen herausragenden Beitrag zum Unternehmenserfolg leistet. Die

Lean-Adaptive Philosophie wird in der Organisation gelebt und kontinuierlich durch

Praktiken und Methoden erweitert (91–100%).

Die Reifephasen beschreiben den aktuellen RG des Lean-Adaptive PPM einer Organisa-

tion durch eine Einordnung und Zusammenführung der Dimensionen und soll Anwender-

unternehmen eine Einordnung ihrer PPM-Fähigkeiten und -Entwicklungsstufe geben.

4.3 Gewichtung der Dimensionen und Inhalte

Eines der Forschungsziele war die Priorisierung der Prozesse, Rollen und Prinzipien. Der

Erfüllungsgrad (EPPM) ist essenziell für die Ermittlung der Reifephase des Anwenderun-

ternehmens und bezeichnet dabei das Verhältnis des erreichten Ist-Zustandes zum maxi-

mal erreichbaren Wert (100%). EPPM ergibt sich somit aus dem Durchschnitt aller erreich-

ten (Teil-)Erfüllungsgrade für die Dimensionen Prozesse, Rollen und Prinzipien:

 = Ø ( + +)

Die Dimensionen gehen mit unterschiedlicher Gewichtung („G“) in das Gesamtergebnis

ein: Prozesse mit 50%, Rollen mit 20% und Prinzipien mit 30%. Die Festlegung der Ge-

wichte der Dimensionen basiert auf der Diskussion mit den beteiligten PPM-Experten.

Grundlage der Annahme ist, dass PPM ohne Prozesse zwangsläufig nicht umsetzbar ist,

jedoch durchaus ohne ein Rollenmodell und Prinzipienkanon grundlegende Aufgaben er-

füllen kann. Da die Prinzipien einen großen Anteil am LAUP²-Referenzmodell innehaben

wird die Gewichtung der Prinzipien jedoch über den Rollen angesetzt. Es ergibt sich:

 = Ø ( ∙  + ∙  + ∙ )

Um eine möglichst aussagekräftige Einschätzung der PPM-Reife vornehmen zu können

wurden die Inhalte ebenfalls gewichtet. Ausgangslage bildete die Gewichtung der Pro-

zesse. Dafür wurden die Prozesse anhand von strategischen Erfolgsfaktoren bewertet

[Sc24]. Die dazu herangezogenen Erfolgsfaktoren stammen aus einer umfangreichen

MPM-Studie der TU Darmstadt [KG22]. Zunächst wurden die in der Studie identifizierten

Erfolgsfaktoren auf ihre Eignung hinsichtlich Prozessbewertung überprüft. Daraufhin

wurden die Prozesse anhand der Erfolgsfaktoren durch ein Scoring-Modell bewertet, um

so eine geclusterte Gewichtung abzuleiten [Hü24] ‒ im Ergebnis:

- PPM System Strategy Determ.

- Benefits Management

- Project Portfolio Authorization

- Development of PPM Methods

- PPM-Governance

- PPM-System Operations

- Project Demand Management

- Informat. & Knowledge Mgmt.

- Performance Management

- Client & Stakeholdermgmt.

- Resource Management

- Risk Management

Dem Ergebnis der Gewichtung ist zu entnehmen, dass der PP-Authorization-Prozess mit

15 Pkt. als „wichtigster“ Prozess eingestuft wird, während die Prozesse aus den LAUP2-

Prozessbereichen PPM-System-Bereitstellung und Querschnittsprozesse mit jeweils 5 Pkt.

geringer gewichtet werden.

170 Claus Hüsselmann und Janek Hergenröder

Die Gewichtung der Prozesse bildet zugleich die Grundlage für die Gewichtung der Rol-

len. Die vorgeschlagene RACI-Matrix des LAUP2-Modells [Hü24] schafft eine Möglich-

keit, die Rollen anhand der Prozesse zu bewerten, indem für die verschieden Verantwor-

tungsstufen eine Punktzahl vergeben wird. Die Rolle, die durchführungsverantwortlich für

den jeweiligen Prozess ist, bekommt die höchste Punktzahl in dem Scoring Modell:

- Strategy Sponsor

- Operational PMO

- PPM Sponsor

- Project Portfolio Board

- Project Portfolio Manager

- Steering Committee

- Project Portfolio Analyst

- Subject Manager

- Resource Coordinator

- Knowledge Manager

- Project/Program Sponsor

- Domain Authority

- Program Manager

- Project Manager

- Project Management Expert

- Project Team Member

- Strategic PMO

Das Project Portfolio Board erhält als Durchführungsverantwortlicher („R“ im RACI-

Modell) des PP-Authorization-Prozesses die höchste Gewichtung. Dies liegt in der Aus-

wertung der Rollen begründet, bei der mithilfe einer Max-Funktion die Gewichtung abge-

leitet wird. Grund dafür ist, dass die durchführungsverantwortlichen Rollen der wichtigs-

ten Prozesse bei einer summarischen Betrachtung als „unwichtiger“ eingestuft werden

könnten, als Rollen, die in vielen Prozessen beteiligt sind.

Die (Kern-)Prinzipien werden nicht gewichtet, da sie in ihrer Bedeutung als gleichwertig

betrachtet werden [Hü24]. Damit ist die Gewichtung der Dimensionen und Inhalte abge-

schlossen. Für die Ermittlung der Erfüllungsgrade der Dimensionen sind die Bewertungs-

ergebnisse der Reife mit den ermittelten Gewichten der einzelnen Objekte zu bewerten.

Durch die dreidimensionale Bewertung ist eine rasterbasierte Darstellung nicht umsetzbar.

Die Bewertung erfolgt durch eine Selbstbewertung anhand einer Skala mit lediglich drei

Auswahlmöglichkeiten, die im gleichen Stil gestaltet ist. Durch den Einsatz einer Skala

kann das LAUP²-RG-Modell als hybrides Reifegradmodell betrachtet werden [FMG02].

Zusätzlich zur Bewertung mithilfe der Skala muss eine Indikation gegeben werden. Die

Indikation kann als ein Beweis für die Erfüllung des Reifegrades verstanden werden, in-

dem z.B. genutzte Kennzahlen, Methoden oder Rollenprofile angegeben werden. Alle Be-

wertungsobjekte werden in kurzer und prägnanter Form beschrieben. Darüber hinaus wer-

den grundsätzliche Beschreibungen der Dimensionen mit an die Hand gegeben.

5 Anwendung des entwickelten Reifegradmodells

Die Anwendung des LAUP²-RG-Modell gliedert sich, in Anlehnung an das AAF, in einen

zweistufigen Prozess [SAB07]:

(1) Ermittlung der Reife: Die Ermittlung der Reife (Ist-Zustand) wird innerhalb eines mo-

derierten Workshops in Form einer Selbstbewertung durchgeführt [HH25]. Die Work-

shop-Teilnehmer bewerten anhand der Skala, den generischen Beschreibungen sowie An-

Lean-Adaptive PPM-Reifegrad 171

kerelementen jedes Betrachtungsobjekt. Innerhalb der Ermittlung der Reife wird auch ein-

Soll-Zustand definiert [SAB07].

(2) Ableitung von Verbesserungsmaßnahmen: Aufbauend auf der Abweichungsanalyse

von Ist- und Soll-Zustand können im Anschluss Maßnahmen definiert werden, um den

angestrebten Zustand zu erreichen. Das Modell gibt dabei durch die Ankerelemente bereits

erste Werkzeuge und Methoden an die Hand. Für die konkrete Ableitung von Maßnahmen

wird im Rahmen der Anwendung des LAUP²-RG-Modells ein zweiter Workshop sinnvoll.

Das entwickelte RG-Modell wurde mit den Experten des PMO von SunExpress im Rah-

men von zwei entsprechenden Tagesworkshops praktisch durchgeführt und evaluiert.

Nachfolgend werden die Ergebnisse der Anwendung des RG-Modells vorgestellt.

5.1 Ergebnisse der Reifegraderhebung

Der durchschnittliche Reifegrad in der Dimension Prozesse beträgt 3,1 (Median 3,5). Die

Prozesse PPM System Strategy Determination, Resource Management und Benefits Ma-

nagement weisen den niedrigsten Reifegrad auf. Den höchsten Reifegrad erzielt das Un-

ternehmen im Prozess Information & Knowledge Management, gefolgt von PPM System

Operations und Risk Management. Auf der Basis der Erhebung kann eine Analyse der

Abweichung von Ist- und Soll-Zustand vorgenommen werden (siehe Abbildung 3).

Die X-Achse beschreibt den Abstand von Ist-Zustand zu Soll-Zustand und die Y-Achse

den Abstand von Ist-Zustand zum maximal erreichbaren Level. Die Prozesse werden an-

hand der Evaluationsergebnisse eingeordnet. Umso weiter rechts ein Prozess eingeordnet

wird, desto größer ist der Abstand zwischen Soll- und Ist-Zustand. Umso höher ein Pro-

zess eingeordnet wird, desto niedriger ist der Reifegrad im Ist-Zustand. Damit kann si-

chergestellt werden, dass eine Organisation trotz der Fokussierung auf spezielle Bereiche

auch generell auf dem Entwicklungspfad voranschreitet.

Den niedrigsten Reifegrad erzielen die Rollen der Knowledge Manager und Resource

Coordinator. Die Rollen Strategic PMO, Project Manager und Project Portfolio Manage-

ment Sponsor erzielen bereits den höchstmöglichen Reifegrad. Der durchschnittliche Rei-

fegrad in der Dimension Rollen beträgt 2,8 (Median 3,0). Für die Ableitung von Maßnah-

men wird wieder ein Blick auf die Abweichungsanalyse in Abbildung 4 gerichtet.

Abbildung 4 kann entnommen werden, dass die Rollen Knowledge Manager, Resource

Coordinator, Subject Manager und Domain Authority eine hohe Priorität innehaben. Re-

lativ knapp in den Bereich hohe Priorität fallen zudem die Rollen Project Management

Expert und Program Manager.

SunExpress kann bereits eine ausgeprägte Prinzipienorientierung vorweisen. Besonders

im Bereich der Kundenorientierung ist bereits ein hoher Reifegrad in der Organisation

vorhanden. Der durchschnittliche Reifegrad der Dimension Prinzipien beträgt 3,1 (Median

3,0). Anhand der Abweichungsanalyse (Abbildung 5) wird nur ein Prinzip mit hoher Pri-

orität identifiziert: Menschenorientierung.

172 Claus Hüsselmann und Janek Hergenröder

Abbildung 3: Abweichungsanalyse Prozesse

Abbildung 4: Abweichungsanalyse Rollen

Nachdem die einzelnen Dimensionen und ihre Ergebnisse vorgestellt wurden, werden die

Ergebnisse nun gemäß der festgelegten Logik zusammengeführt, um so eine Aussage über

die PPM-Reife der Fluggesellschaft in Bezug zum LAUP²-Referenzmodell treffen zu kön-

nen. Dabei entstehen die in Abbildung 6 gezeigten Resultate für die einzelnen Dimensio-

nen.

Zusammengeführt ergibt sich für den Ist-Zustand ein Erfüllungsgrad EPPM von 58%. Für

den Soll-Zustand werden 84% berechnet. Anhand der Ergebnisse lässt sich SunExpress in

Reifephase 3 ‒ Sustainable PPM verordnen.

PPM System Strategy Determination

Project Portfolio Authorization

PPM-Governance

Project Demand Management

Performance Management

Resource Management

Benefits Management

Development of PPM

Methods & Tools

PPM-System Operations

Information & Knowledge Management

Client & Stakeholder

Management

Risk Management

0,5

1,5

2,5

3,5

4,5

00,5 11,5 22,5 33,5 44,5 5

Gap: Max. level

Gap: To Be Level

Strategy Sponsor

Project Portfolio Management Sponsor

Project Portfolio Manager

Project Portfolio Analyst

Resource Coordinator

Project/Program Sponsor

Program Manager

Project Management Expert

Strategic

PMO

Operational PMO

Project Portfolio Board

Program/Project Steering

Committee

Subject Manager

Knowledge Manager

Domain Authority

Project Manager (Product / Process)

Project Team Member

0,5

1,5

2,5

3,5

4,5

00,5 11,5 22,5 33,5 44,5 5

Gap: Max. level

Gap: To Be Level

Lean-Adaptive PPM-Reifegrad 173

Abbildung 5: Abweichungsanalyse Prinzipien

Die ange

strebte Reife-

phase ist

Principle-ba-

sed PPM. Um diese

Phase ggf. bei einer er-

neuten Evaluation zu

erreichen, müssen eine

Reihe von Verbesse-

rungsmaßnahmen defi-

niert und umgesetzt

werden. Somit erfolgt

die Überleitung zur

Handlungsempfehlung.

Abbildung 6: Resultate der Dimensionen

5.2 Abgeleitete Handlungsempfehlungen

Für die Weiterentwicklung des PPM im Beispielunternehmen wurden auf Basis der Ana-

lyse mehrere priorisierte Handlungsfelder identifiziert. Im Bereich der Prozesse steht zu-

nächst die PPM System Strategy Determination im Fokus. Hier besteht ein erheblicher

Entwicklungsbedarf (Prozessreife auf Stufe 1 ‒ Initial, Ziel: Stufe 4 ‒ Managed). Um die-

sen Reifegrad zu erreichen, wurde empfohlen, klare Portfolioziele und eine Portfoliostra-

tegie zu definieren, die eng mit der Unternehmensstrategie verknüpft sind. Ein konkreter

Ansatz hierfür ist die Einführung sogenannter Strategic Buckets, durch die Budgets auf

strategische Ziele ausgerichtet und ein ausgewogenes Projektportfolio sichergestellt wer-

den können. Ergänzend dazu sollte eine PPM-spezifische Balanced Scorecard (PPM-

BSC) implementiert werden, um die Unternehmensvision und -strategie in messbare Leis-

tungsfaktoren zu übersetzen und als Rahmen für die Steuerung und Rückkopplung der

Managementprozesse zu dienen [Hü24].

Kundenorientierung

Prozessorientierung

Engpassorientierung

Adaptivität

Minimalität

Strategieorientierung

Menschenorientierung

0,5

1,5

2,5

3,5

4,5

00,5 11,5 22,5 33,5 44,5 5

Gap: Max. level

Gap: To Be Level

57% 56%

61%

80% 80%

94%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Prozesse Rollen Prinzipien

Erfüllungsgrad E

Resultate der Dimensionen

Achieved To Be Level

174 Claus Hüsselmann und Janek Hergenröder

Im Bereich Benefits Management befindet sich die Organisation aktuell zwischen Stufe 1

(Initial) und Stufe 2 (Wiederholbar), mit dem Ziel, Stufe 4 (Managed) zu erreichen. Bisher

erfolgt keine zufriedenstellende Nachverfolgung des Projektnutzens, allerdings wurde be-

reits mit der Entwicklung eines „Business Case Trackers“ begonnen. Um die angestrebte

Prozessreife zu erreichen, sollte dieser Ansatz weiterverfolgt und durch die Einführung

von Kennzahlen ergänzt werden, die eine kontinuierliche und messbare Bewertung des

Projektnutzens ermöglichen.

Auch im Resource Management wurde ein niedriger Reifegrad festgestellt (Stufe 1 – Ini-

tial), wobei das Ziel auf Stufe 3 (Definiert) liegt. Die zunehmende Anzahl von Ressour-

cenkonflikten und das Fehlen einer systematischen Kapazitätsplanung machen deutlich,

dass eine vorausschauende Ressourcenplanung erforderlich ist. Es wurde daher empfoh-

len, den Ressourcenbedarf und die Anforderungen der Projekte frühzeitig zu planen und

zu visualisieren, um mögliche Engpässe rechtzeitig zu erkennen und zu vermeiden.

Für den Bereich Rollen konnten aufgrund fehlender Ankerelemente und unzureichender

Kenntnisse der organisatorischen Strukturen keine konkreten Handlungsempfehlungen

abgeleitet werden. Es wurde empfohlen, dieses Thema in einem weiteren Verlauf vertieft

zu behandeln.

Bei den Prinzipien wurde insbesondere die Menschenorientierung als prioritäres Hand-

lungsfeld identifiziert. Der aktuelle Reifegrad liegt hier auf Stufe 2 (Konzeptionell), wäh-

rend langfristig Stufe 5 (Ganzheitlich) angestrebt wird. Zur Steigerung der Reife wird die

Einführung stabiler Teams empfohlen, um die Zusammenarbeit und Effizienz zu fördern.

Die Anwendung von Pull-Prinzipien kann zudem dazu beitragen, die Arbeitsbelastung der

Teams zu begrenzen und die Selbstorganisation zu stärken [Hü24]. Ergänzend sollten re-

gelmäßige Mitarbeiterumfragen durchgeführt werden, um gezielt auf die Bedürfnisse und

Verbesserungsvorschläge der Mitarbeitenden eingehen zu können.

Zusammenfassend zielen die Maßnahmen darauf ab, die Reife der zentralen PPM-Pro-

zesse signifikant zu erhöhen, die Menschenorientierung zu stärken und ein strategisch aus-

gerichtetes, effektives Projektportfoliomanagement zu etablieren. Die Entwicklung und

Implementierung passender Rollen bleibt ein offener Punkt, der in einem nächsten Schritt

adressiert werden soll.

6 Resümee

Ziel war es, ein praxisorientiertes Instrument zur Bewertung und Weiterentwicklung des

PPM in Unternehmen zu schaffen. Es wurde ein Reifegradmodell mit den drei Dimensio-

nen Prozesse, Rollen und Prinzipien entwickelt. Jede Dimension kann unabhängig bewer-

tet werden und trägt zur Gesamteinschätzung der PPM-Reife bei. Eine Gewichtung inner-

halb des Modells ermöglicht die Hervorhebung besonders relevanter Elemente, wodurch

gezielte Entwicklungspfade und die Identifikation von Schwächen ermöglicht werden. Die

Erprobung bei der Fluggesellschaft SunExpress war erfolgreich. Die Akzeptanz war hoch,

und es wurde ein systematischer Bewertungs- und Verbesserungsprozess etabliert. Das

Unternehmen befindet sich mit einem Reifegrad von 58 % in der Phase „Sustainable

PPM“. Ankerelemente ermöglichen eine gezielte Ableitung von Maßnahmen, zeigen aber

Lean-Adaptive PPM-Reifegrad 175

noch Entwicklungspotenzial, etwa durch die Integration weiterer Methoden und Prakti-

ken. Das Modell wird grundsätzlich als funktional angesehen, weist jedoch Optimierungs-

bedarf bei der Validierung der Reifegrade und der Ausgestaltung der Ankerelemente auf.

Das LAUP²-RG-Modell wird schließlich anhand der definierten Anforderungen evaluiert

und hinsichtlich ihres Erfüllungsgrads bewertet (voll, teils, nicht):

A1 – Bewertung der aktuellen PPM-Reife: Die Standortbestimmung wurde erfolgreich

durchgeführt. Erfüllungsgrad: voll

A2 – Entwicklungspfad vorgeben: Ein evolutionärer Reifegradpfad ist vorhanden, jedoch

fehlt eine methodische Validierung der Reifestufen. Erfüllungsgrad: teils

A3 – Unterstützung der Weiterentwicklung: Das Modell erlaubt gezielte Identifikation und

Weiterentwicklung von Fähigkeiten auf Dimensionsebene. Erfüllungsgrad: voll

A4 – Unterstützung des Fortschritts: Die Ableitung von Maßnahmen ist grundsätzlich

möglich, jedoch sind die Ankerelemente noch unzureichend konkretisiert. Erfüllungs-

grad: teils

A5 – Einfache Anwendung: Die Anwendung ist grundsätzlich einfach, jedoch ist eine ge-

wisse Vorbereitung notwendig. Das Ziel eines Tagesworkshops wurde erfolgreich umge-

setzt. Erfüllungsgrad: voll

A6 – Abdeckung der Inhalte: Prozesse und Rollen sind vollständig abgedeckt, bei den

Grundsätzen besteht jedoch noch Integrations- und Präzisierungsbedarf. Erfüllungsgrad:

teils

Das Modell erfüllt zentrale Anforderungen (keine Anforderung wurde als „nicht erfüllt“

eingestuft), weist jedoch zwei wesentliche Optimierungsfelder auf: fehlende Validierung

der Reifegrade und unvollständige methodische Ausgestaltung der Ankerelemente. Durch

den Bezug zum Lean-Adaptive PPM mit seinem universellen Paradigma der Vermeidung

nicht-wertschöpfender Arbeit ist grundsätzlich keine polarisierte Ausrichtung des PPM

des Unternehmens (zwischen agil und stabilitätsorientiert) vorgegeben ‒ diese kann und

sollte dem Ansatz „Approach follows Context“ folgen.

7 Literaturverzeichnis

[Al14]

Albrecht, J.C.: Einfluss der Projektmanagementreife auf den Projekterfolg.

Empirische Untersuchung im Industriebereich und Ableitung eines Vorge-

hensmodells. Dissertation (Schriftenreihe Projektmanagement, 19)

, Uni-

versität

Kassel 2024

[AX19]

AXELOS Limited: PRINCE2 Agile German, S.l. 2019.

[BKP09]

Becker, J.; Knackstedt, R.; Pöppelbuß, J.: Entwicklung von Reifegradmo-

dellen für das IT

-Management, in: WIRTSCHAFTSINFORMATIK, Jg.

51, Heft 3, 2009, S. 249

–260. https://doi.org/10.1007/s11576-009-0167-9.

176 Claus Hüsselmann und Janek Hergenröder

[Br05]

Bruin, T. de; Freeze, R.; Kulkarni, U.; Rosemann, M.: Understanding the

Main Phases of Developing a Maturity Assessment Model, ACIS 2005

Proceedings.

109, https://aisel.aisnet.org/acis2005/109 (am 22.2.2024).

[Br21]

Bruhn, M.: Qualitätsmanagement für Non-Profit-Organisationen. Grundla-

gen

– Planung – Umsetzung – Kontrolle, 2. Aufl., Wiesbaden/Heidelberg

2021.

[Bu23]

Buehring, S.: Portfolio, Programme, and Project Management Maturity

Model (P3M3), 2023.

[CM10]

CMMI Product Team: CMMI® for Development. Version 1.3, 2010.

[De20]

Dechange, A.: Projektmanagement - schnell erfasst, Berlin/Heidelberg

2020.

[DI13]

DIN Deutsches Institut für Normung e.V.: DIN 69909-1. Multiprojektma-

nagement

- Management von Projektportfolios, Programmen und Projekten

Teil 1: Grundlagen, ICS 03.100.40 (Onlineveröffentlichung aus dem Jahr

2013).

[EF20]

EFQM: Das EFQM Modell. Enthält ergänzende Informationen zu Anwen-

dungsbeispielen, RADAR und Bewertungsprofilen, 2020.

[FMG02]

Fraser, P.; Moultrie, J.; Gregory, M.: The use of maturity models/grids as a

tool in assessing product development capability, in: Managing technology

for the new economy. St John's College, Cambridge, UK, 18

- 20 August

2002; proceedings, Piscataway, NJ 2

002, S. 244–249.

[Fr23]

Frick, A.: Projekt- und Multiprojektmanagement richtig aufbauen. Baukas-

ten und Leitfaden zur Steuerung projektorientierter Organisationen, 2.

Aufl., Wiesbaden/Heidelberg 2023.

[GP23]

GPM [Hrsg.]: Projektifizierung 2.0. Zweite Makroökonomische Vermes-

sung der Projekttätigkeit in Deutschland, Tübingen 2023.

[HAN19]

Hirzel, M.; Alter, W.; Niklas, C. [Hrsg.]: Projektportfolio-Management.

Strategisches und operatives Multi

-Projektmanagement in der Praxis, 4.

Aufl., Wiesbaden/Heidelberg 2019.

[HH25]

Hüsselmann, C.; Hergenröder, J.: Reifegradmodell für Lean-Adaptive Pro-

ject Portfoliomanagement ‒ Entwicklung und Anwendung

, 2., korr. Aufl.,

-Report 022, TH Mittelhessen 2025. http://dx.doi.org/10.25716/thm-398

[HK12]

Hertneck, C.; Kneuper, R.: Prozesse verbessern mit CMMI for Services.

Ein Praxisleitfaden mit Fallstudien, Heidelberg 2012.

[Hö12]

Höltz, N.: Lean Logistics Maturity Model. Ein Reifegradmodell zur Be-

wertung schlanker intralogistischer Unternehmensstrukturen, 2012.

Lean-Adaptive PPM-Reifegrad 177

[Hü21]

Hüsselmann, C.: Lean Project Management. Hybride Methoden wertschöp-

fend anwenden, Stuttgart 2021.

[Hü24]

Hüsselmann, C.: Lean-Adaptive Project Portfolio Management. Ein pro-

zess

- und prinzipienorientiertes Referenzmodell, Stuttgart 2024.

[Jø07]

Jørgensen, F.; Matthiesen, R.; Nielsen, J.; Johansen, J.: Lean Maturity,

Lean Sustainability, in: Olhager, J.; Persson, F. [Hrsg.]: Advances in pro-

duction management systems. International IFIP TC 5, WG 5.7 Conference

on Advances in Production Management S

ystems (APMS 2007), Septem-

ber 17

-19, Linköping, Sweden, New York, NY 2007, S. 371–378.

[KG22]

Kock, A.; Gemünden, H. G.: Befunde der 10. Multiprojektmanagement-

Studie,

TU Darmstadt/TU Berlin 2022.

[Kü13]

Kübel, M.: Corporate M&A. Reifegradmodell und empirische Untersu-

chung, Wiesbaden 2013.

[LR08]

Linssen, O.; Rachmann, A. [Hrsg.]: OPM3 – ein Reifegradmodell für das

unternehmensweite Projektmanagement, Aachen 2008.

[LW19]

Lang, M.; Wagner, R. [Hrsg.]: Der Weg zum projektorientierten Unterneh-

men

- Wissen für Entscheider, München 2019.

[MRW09]

Mettler, T.; Rohner, P.; Winter, R.: Towards a Classification of Maturity

Models in Information Systems. VI conference of the Italian Chapter of the

Association for Information Systems (ItAIS), Olbia 2009.

[OD13]

Ozcan-Top, O.; Demirörs, O.: Assessment of Agile Maturity Models: A

Multiple Case Study, in: Woronowicz, T.; Rout, T.; Dorling, A.; O'Connor,

R. V. [Hrsg.]: Software process improvement and capability determination.

13th international conference, SPICE 201

3, Bremen, Germany, June 4 - 6,

2013; proceedings, Berlin/Heidelberg 2013, S. 130

–141.

[PM24]

PM Solutions: P3M3® MATURITY ASSESSMENTS. THE P3M3®

MODEL, https://pmsolutionsaustralia.com.au/consulting/p3m3

-maturity-

assessments/, am 22.2.2024.

[Pr03]

Project Management Institute: Organizational project management ma-

turity model.

OPM3 knowledge foundation, Newtown Square, Pa. 2003.

[Pr17a]

Project Management Institute: A guide to the project management body of

knowledge.

(PMBOK® guide), Newtown Square, Pennsylvania 2017.

[Pr17b]

Project Management Institute: The Standard for Portfolio Management —

Fourth Edition, 4.

Aufl., Erscheinungsort nicht ermittelbar/Boston, MA

2017.

[Ri19]

Rietsch, J.: Projektportfolio-Management. Strategische Ausrichtung und

Steuerung von Projektlandschaften, 2. Aufl., Freiburg u.a. 2019.

178 Claus Hüsselmann und Janek Hergenröder

[SAB07]

Sidky, A.; Arthur, J.; Bohner, S.: A disciplined approach to adopting agile

practices: the agile adoption framework, in: Innovations in Systems and

Software Engineering, Jg. 3, Heft 3, 2007, S. 203

–216.

https://doi.org/10.1007/s11334

-007-0026-z.

[Sc24]

Schmidhauser, K.: Prozessmanagement im Mittelstand,

https://sgbs.ch/publication/prozessmanagement

-im-mittelstand-theorie-vor-

gehensweise

-fallstudie-am-beispiel-der-giesserei-ag/4-2-1-1-prozess-ein-

fluss

-auf-strategische-erfolgsfaktoren, am 20.4.2024.

[Se11]

Seidl, J.: Multiprojektmanagement. Übergreifende Steuerung von Mehr-

projektsituationen durch Projektportfolio

- und Programmmanagement,

Berlin/Heidelberg 2011.

[SG10]

Solli-Sæther, H.; Gottschalk, P.: The Modeling Process for Stage Models,

in: Journal of Organizational Computing and Electronic Commerce, Jg. 20,

Heft 3, 2010, S. 279

–293. https://doi.org/10.1080/10919392.2010.494535.

[So18]

Sommerhoff, B.: EFQM zur Organisationsentwicklung, 2. Aufl., München

2018.

[St15]

Steinle, C. [Hrsg.]: Handbuch Multiprojektmanagement und -controlling.

Projekte erfolgreich strukturieren und steuern, 3. Aufl., Berlin 2015.

[Su24]

SunExpress: Unternehmens-Website, https://www.sunexpress.com/de/un-

ternehmen/die

-sunexpress-welt/, am 12.2.2024.

8 Anhang

Prozess-Reifegrade

1 ‒ Initial: Der Prozess wird ad-hoc oder reaktiv durchgeführt und führt zu unvorherseh-

baren Ergebnissen. Das Engagement und das Fachwissen der Mitarbeiter bestimmen die

Prozessqualität; es gibt keine ausdrückliche organisatorische Unterstützung.

2 ‒ Wiederholbar: Der Prozess wird gemäß einer Prozessbeschreibung geplant, durchge-

führt und überwacht. Die Arbeitsprodukte werden in geeigneter Weise kontrolliert. Die

einheitliche Anwendung des Prozesses ist jedoch nicht gewährleistet, so dass die Prozes-

sergebnisse schwanken.

3 ‒ Definiert: Der Prozess ist gut definiert, dokumentiert und verstanden. In einem defi-

nierten Prozess sind Zweck, Inputs, Eingangskriterien, Aktivitäten, Rollen, Maßnahmen,

Überprüfungsschritte, Outputs und Ausgangskriterien eindeutig festgelegt. Alle Beteilig-

ten würden diese Leitlinien verstehen und eine einheitliche Anwendung sicherstellen.

4 ‒ Quantitativ geführt: Darüber hinaus wird ein Prozess der Reifegradstufe 4 mit Hilfe

statistischer und anderer quantitativer Verfahren gesteuert. Es werden quantitative Ziele

für die Qualität und die Prozessleistung festgelegt und die Wirksamkeit des Prozesses ist

bekannt. Die Leistung ist quantitativ vorhersehbar.

Lean-Adaptive PPM-Reifegrad 179

5 ‒ Optimiert: Der Prozess wird auf der Grundlage eines umfassenden Verständnisses

der häufigsten Ursachen für prozessbedingte Abweichungen kontinuierlich bewertet und

verbessert. Der Schwerpunkt liegt auf der kontinuierlichen Optimierung des Leistungs-

spektrums des Prozesses durch inkrementelle und innovative Verbesserungen.

Rollen-Reifegrade

1 ‒ Initial (>10%): Die Rolle wird teilweise ad hoc oder reaktiv von einzelnen Mitarbei-

tern (Heroes) wahrgenommen. Es gibt keine explizite Rollenbeschreibung.

2 ‒ Definiert (>30%): Die Rolle ist für die Organisation vorgesehen und beschrieben/de-

finiert. Obwohl die Rolle beschrieben ist, wird sie nicht einheitlich umgesetzt und ausge-

führt.

3 ‒ Ausgeführt (>50%): Die Rolle ist klar definiert, wird ausgeführt und gelebt. Die Per-

sonalkapazitäten sind auf die Ausführung der Rolle ausgerichtet. Die Rolle ist allen Be-

teiligten bekannt und wird von ihnen verstanden.

4 ‒ Fortgeschritten (>70%): Darüber hinaus ist die Rolle im gesamten Unternehmen

weithin akzeptiert und geschätzt. Es gibt Schulungen für die Rolle und spezielle Karrier-

ewege für diese Rolle. Die Auswirkungen der Rolle können gemessen werden.

5 – Optimiert (>90%): Die Rolle wird kontinuierlich evaluiert und auf der Grundlage

der Ergebnisse verbessert. Die Rolle wird an die Zielgruppe angepasst, um die Akzep-

tanz zu erhöhen.

Prinzipien-Reifegrade

1 ‒ Initial: Das Prinzip ist teilweise bekannt und wird sporadisch berücksichtigt. Es wer-

den jedoch keine Methoden oder Werkzeuge für die konkrete Umsetzung verwendet.

2 ‒ Konzeptionell: Das Prinzip ist in der Organisation bekannt, wird aber nicht konkret

umgesetzt. Es findet also keine organisationsweite Berücksichtigung statt. Stattdessen

wenden die einzelnen Teams das Prinzip an, manchmal unbewusst.

3 ‒ Integriert: Das Prinzip ist in der gesamten Organisation bekannt und es werden An-

strengungen zu seiner Umsetzung unternommen. Es gibt noch keine festen Methoden

und Praktiken, die als Standard eingeführt werden, aber es werden Methoden verwendet.

4 – Systematisch: Das Prinzip wird systematisch umgesetzt. Praktiken und Methoden,

die sich als erfolgreich erwiesen haben, wurden für die Umsetzung definiert.

5 ‒ Ganzheitlich: Das Prinzip wird umfassend und ganzheitlich praktiziert. Die einge-

setzten Methoden und Instrumente werden kontinuierlich ausgebaut und weiterentwi-

ckelt. Die Methoden und Instrumente erzielen hervorragende Ergebnisse und sind auf die

Bedürfnisse des Unternehmens zugeschnitten.

180

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 181

How to Mitigate Technical Debt in Startups: Extending the

Entrepreneurial Software Engineering Model

Jil Klünder1, Florian Heintz2, Jakob Droste3, Mario Wiese4 und Marco Kuhrmann5

Abstract: Several software startups fail due to the competitive environment, time constraints,

limited financial ressources, and other aspects. To overcome some of these issues, in particular

regarding time and finance, startups try to release their software product as quickly as possible. For

this, they often cut corners on different aspects of the product, unconsciously accepting technical

debt. We argue that startups are often not aware of long-term effects of technical debt and, hence,

unconciously accept software- and process-related shortcomings when developing the product. In

order to raise the awareness for technical debt and to help startups avoid it, we extend the

Entrepreneurial Software Engineering Model grounded in insights from literature. For each software

development phase in startups, our extension puts special emphasis on technical debt, e.g., by

integrating aspects such as architecture testing and specific quality gates that are often not part of

software processes in early stage startups.

Keywords: Entrepreneurial Software Engineering, Technical Debt, Software Startups

1 Introduction

There is an increasing number of startups whose product is based on software. However,

despite innovative and promising ideas, several startups fail for different reasons. Due to

the competitive environment, time constraints, limited financial resources, and other

aspects, startups try to deliver their product as soon as possible. To achieve this, they often

cut corners on different aspects of the product, such as quality assurance or risk

management [KMK22]. This way, they unconsciously accept technical debt which has

been proven to have negative long-term effects on software development. As in other

companies, startups are unlikely aware of these long-term effects and, hence, accept

software- and process-related shortcomings when developing the software product.

1 University of Applied Sciences | FHDW Hannover, Freundallee 15, 30173 Hannover, Germany,

jil.kluender@fhdw.de, https://orcid.org/0000-0001-7674-2930

2 Électricité de Strasbourg, Strasbourg, France; formerly Leibniz University Hannover, Hannover, Germany,

florianheintz22@gmail.com philipp.straub@reutlingen-university.de, https://orcid.org/0009-0003-3868-

5789

3 Leibniz University Hannover, Software Engineering Group, Welfengarten 1, 30167 Hannover, Germany,

jakob.droste@inf.uni-hannover.de, https://orcid.org/0000-0001-8746-6329

4 University of Hamburg, Department of Informatics, Vogt-Kölln-Str. 30, 22527 Hamburg, Germany,

marion.wiese@uni-hamburg.de, https://orcid.org/0000-0003-0160-9531

5 Reutlingen University, Herman Hollerith Center, Danziger Str. 2, 71034 Böblingen, Germany,

kuhrmann@acm.org, https://orcid.org/0000-0001-6101-8931;

philipp.straub@reutlingen-university.de, https://orcid.org/0009-0003-3868-5789

182 Jil Klünder et al.

Besides difficulties introduced by technical debt, they also struggle with their software

development in general [KMK22].

Guidelines supporting startups developing software is provided by the Entrepreneurial

Software Engineering model [BMK21; KMK22]. This model summarizes concrete steps

regarding feature generation, design and user experience, pre-launch testing, and the

development of the single feature minimum viable product (MVP). In order to further raise

the awareness for technical debt and to help startups avoid it, we synthesize knowledge

from literature to extend the Entrepreneurial Software Engineering model putting special

emphasis on technical debt. By construction, we provide guidelines that points to aspects

to be considered in order to avoid, identify, manage, and monitor technical debt. These

aspects include a continuous technical debt as well as the integration of different testing

methods such as architecture testing, as architecture development has already been

identified as a shortcoming in startup software development [KMK22].

Context. This paper is based on Heintz’ master thesis [He24] entitled Avoiding technical

debt in startups when developing software. Further details on the study as well as more

detailed results are available online 6.

2 Background and Related Work

Several researchers focus on technical debt and how it can be avoided. Avgeriou et al.

[Av16] define technical debt as “a collection of design or implementation constructs that

are expedient in the short term, but set up a technical context that can make future changes

more costly or impossible” . To gain an overview of existing research, Li et al. [LAL15]

as well as Rios et al. [RMS18] conducted a literature study summarizing technical debt

types and strategies how to manage the different types. They further identified research

trends and provide information for practitioners. Rios et al. [RMS18] also provided

definitions for a total of 15 different technical types and outlined, in which situations these

types often occur.

A conceptual model of TD was defined during a Dagstuhl seminar describing TD causes,

consequences, types and activities as well as a model of how TD items interact with their

surroundings, e.g. by creating symptoms in IT systems [Av16].

Fowler [Fo09] differentiates between deliberate and inadvertant incurred technical.

Deliberate technical debts result from a conscious decision, e.g., implementing a

workaround to reach a set deadline. Inadvertant TDs result from mistakes, e.g., poor

design at the code level or architectural decisions that, over time, turn out to have been

wrong.

6 The master thesis can be accessed via https://www.pi.uni-hannover.de/fileadmin/pi/se/Stud-Arbeiten/2024/

Heintz2024.pdf (in German).

How to Mitigate Technical Debt in Startups 183

The insights from Rios et al. [RMS18] were refined in the InsighTD study [Fr20]. Since

2017, researchers from eleven different countries regularly conduct the survey study to

gain empirical data on technical debt and to draw conclusions about their causes and

consequences [Ri19]. The resulting cause-effect-diagrams were used in this paper as a

starting point to integrate technical debt in the Entrepreneurial Software Engineering

model.

This Entrepreneurial Software Engineering Model was proposed by Brunner et al.

[BMK21]. It strives to provide concrete guidelines for a more systematic software

development in startups. The first version of the model was derived based on the

collaboration with the startup Zippr [BMK21]. Consolidating experiences from this

startup and expert interviews resulted in the proposed model that supports startups in

iteratively and incrementally developing a minimum viable product. The model was

refined based on a survey study by Kuhrmann et al. [KMK22] in which they investigated

methodological and technical priorities of startups. Based on their insights, they put further

emphasis on aspects such as requirements engineering and software architecture.

Combining entrepreneurial software engineering and technical debt, Abrahamsson and

Holmqvist [AH23] conducted case studies in different technical startups in Stockholm,

Sweden, to identify reasons why startups accept technical debt. According to their study,

the main reason for accepting technical debt in startups is that there are no short-term

consequences. However, the long-term consequences are considered remarkable by the

surveyed startups, which is why the authors conclude that a systematic technical debt

management is highly relevant for startups. Further, they identified the team constellation

by means of personality traits and knowledge to be of particular importance for the

management of technical debt.

As knowledge on technical debt is often rare in startups, we strive to extend the En-

trepreneurial Software Engineering model to provide startups with a systematic approach

to avoid technical debt when developing their MVP.

3 Methodology

The overall goal of this study is to mitigate technical debt in startups in different phases

of the software development process. To reach this goal, we conduct the following steps:

1. Identify the most relevant types of technical debt to investigate on which types

are most relevant for startups

2. Investigate the causes and consequences of the different types of technical debt

to help startups avoiding them and being aware of potential risks

3. Map the types of technical debt to the phases of the software development

lifecycle based on their prevalence to provide a basis to extend the

Entrepreneurial Software Engineering model

184 Jil Klünder et al.

4. Synthesize the results of the previous steps in an extension of the Entrepreneurial

Software Engineering model

To get a data basis for the first three steps presented above, we conducted a literature

review. Although we did not conduct a systematic literature review, our study was aligned

with guidelines presented by Kitchenham et al. [Ki10]. We started with the scoping

process by conducting a literature search using Google Scholar using the following search

string:

technical debt and (management or prevention or startups or types or tools)

We further extended the result set by searching for every single technical debt type

separately. We included papers that can contribute to achieving our research goal, but

excluded a paper if it did not meet our quality criteria, e.g., in case it was not peer-

reviewed, was not published in established journals or presented at established

conferences, was obviously outdated. We further excluded papers that were not written in

English, German, or French and papers that were not accessible, i.e., behind a paywall.

However, in three cases with papers behind a paywall we contacted the authors to get

access to the paper due to a very limited number of other publications dealing with these

topics. In these three cases, the authors sent us the papers and we were able to include

them in the results set.

As noted by Shull et al. [Sh13], there are some papers that only mention the term “technical

debt” in the title, but are only limitedly related to technical debt. Therefore, we were quite

inclusive when investigating the result set provided by Google Scholar and then skimmed

through the abstract and the conclusion of a total of 74 potentially relevant papers. After

this step, we read the full text of the papers and conducted snowballing to find more

relevant papers to be included in our analysis. Based on the snowballing, we added a total

of 126 papers to our result set. While skimming through these papers, we already classified

them based on the technical debt type and the development phase. We further highlighted

causes and consequences related to the respective technical debt type. This way, we got a

knowledge base that forms the basis for the steps 1 to 3.

Step 1: Identify the most relevant technical debt types. Based on the literature review,

we identified a total of 16 technical debt types. To find the most relevant ones, we ordered

them based on their occurrences in the respective papers. We based our ranking on aspects

deemed relevant in existing papers, namely (1) how often the technical debt type is

relevant for companies [BVG21; MTR20], (2) how often they are considered relevant by

the companies’ management [Go23], (3) how often they were studied in existing papers

[Al16; RMS18], (4) how many methods there are to manage the technical debt type

[LAL15], (5) their criticality when they occur [KVG22], and (6) their causes and negative

effects [Ri20]. This way, the 16 technical debt types were ranked based on their potential

relevance for startups.

Step 2: Investigate causes and consequences of technical debt types. The second step

of our research process is mainly based on two publications by Freire et al. [Fr20] and

Rios et al. [Ri19]. Their results are based on an international study that was conducted

How to Mitigate Technical Debt in Startups 185

since 2017 with 513 participants from 80 software companies. Based on this data basis,

they identified 78 causes and 66 effects, i.e., consequences, of technical debt [Fr20].

Step 3: Map the technical debt types to the development phases. We mapped the

technical debt types to the development phases based on the information provided in the

publications. The mapping directly emerged from the results from the literature review.

However, we put

special emphasis on mapping the technical debt types to the development phases used in

the Entrepreneurial Software Engineering model, namely “Feature Requirements

Generation & Evaluation”, “Design & User Experience Evaluation”, “Pre-Launch

Testing”, and the “Development Cycle”.

Step 4: Extend the Entrepreneurial Software Engineering Model. We synthesized the

results from the previous steps in the Entrepreneurial Software Engineering model by

extending the phases with technical debt management and prevention activities.

4 Results

In the following, we first present general results on technical debt, such as the identified

technical debt types and their relevance for industry. In the second step, we present the

results of synthesizing this knowledge in the extended version of the Entrepreneurial

Software Engineering model.

4.1 Technical Debt in Startups

The first step to avoid technical debt in startups is to decide, which technical debts are to

be mitigated in which part of the project [GSS16]. Technical debt management deals with

this difficulty by consisting of three main activities: technical debt identification, technical

debt monitoring, and technical debt payment [Gr14]. For startups, it is even more relevant

than for other companies to decide which technical debts can be accepted and do not need

to be instantaneously resolved, as technical debt does not always need to have negative

consequences [KL10]. Therefore, startups need to carefully decide which technical debt

to resolve and which to accept.

Martini et al. [MBB16] provide a number of items that increase the likelihood of technical

debt management being successful. Although they focus on large companies, the items

also apply for startups, such as having someone being responsible for and taking care of

technical debt management. Further, technical debt management requires time and budget

that need to be allocated. In addition, the whole team needs to be aware of consequences

of technical debt to see value in avoiding it. According to Martini et al. [MBB16], raising

the awareness of the team for the relevance of avoiding technical debt is difficult. For

startups, this is even more important, as time and budget are rare and investing both of

them to avoid something that becomes relevant at a later point in time is difficult to argue.

186 Jil Klünder et al.

Another relevant difficulty of technical debt management is the prioritization of technical

debt [MBB16].

To overcome the second difficulty, we extracted and prioritized 16 technical debt types

from literature (with 1 being most important) as outlined in Table 1.

Note that this ranking was based on the criteria described in Section 3 and does not reflect

our opinion. In particular the rating of security debt is due to the small number of mentions

in research papers and not due to its small relevance for startups and companies in general.

Please refer to other literature (e.g., [AH23; He24]) for further details on the technical debt

types, in particular on their causes and consequences, and possible mitigation strategies.

4.2 Extension of the Entrepreneurial Software Engineering Model

Based on the information provided in the previous subsection and the insights from the

literature review, we extended the Entrepreneurial Software Engineering model. Figure1

presents the extended version of the Entrepreneurial Software Engineering model. Note

that the changes we made are highlighted in blue. Overall, integrating technical debt into

the model required smaller changes in each of the phases for feature requirements

generation and evaluation, design and unser experience evaluation, pre-launch testing and

the development cycle.

Overall model. Besides the changes we implemented in each phase, we added a

continuous technical debt management phase and the technical debt categorization and

priorizitation to the overall model. From the PLT-TDI phase, but also from the other

phases, we receive technical debt items that are used as input for the technical debt

Categorization & Prioritization (TDCP) phase. In this phase, technical debt user stories

are to be created and technical debt causes and effects are to be identified and used as input

for the development phase. Further, we propose to implement a quality gate before the

single feature MVP launch.

Feature Requirements Generation & Evaluation - TD Prevention (FRGE-TDP). For

the FRGE-TDP phase, we identified the vision video method [KSF20] to reduce the risk

of misinterpreted and misunderstood requirements, causing differing visions across

different stakeholders.

Design & User Experience Evaluation - Technical Debt Prevention (DUXE-TDP). In

the DUXE-TDP phase, we propose to integrate the Minumum Viable User Experience

Tab. 1: Prioritized technical debt types according to literature

1. Design Debt

7. Versioning Debt

12. People Debt

2. Code Debt

8. Defect Debt

13. Usability Debt

3. Test Debt

9. Build Debt

14. Test Automation Debt

4. Architecture Debt

10. Process Debt

15. Service Debt

5. Requirements Debt

11. Infrastructure Debt

16. Security Debt

6. Documentation Debt

How to Mitigate Technical Debt in Startups 187

Framework [HKV16] streamline the process of evaluating the design and the user

experience.

Fig. 1: Entrepreneurial Software Engineering Model [BMK21] extended by technical debt. Changes

are highlighted in blue.

188 Jil Klünder et al.

Pre-Launch Testing - Technical Debt Identification (PLT-TDI). In the PLT-TDI

phase, technical debt items cannot be prevented anymore, but need to be identified.

Therefore, in the testing phase, technical debt items are created that are used as input for

the technical debt categorization and prioritization phase. To support the identification of

technical debt, different types of testing are to be considered and combined in a test

environment that should also be tested. More concretely, besides already existing types of

testing such as security testing, installation testing, and performance testing, aspects such

as architecture testing, infrastructure testing, and usability testing should also be

considered to evaluate the single feature MVP.

Technical Debt Categorization & Prioritization (TDCP). The TDCP phase (see Figure

2) uses the technical debt items identified during the pre-launch testing as input for the

technical debt documentation and the cause and/or effect analysis. The output of these two

activities, namely the technical debt backlog and the cause-effect-diagrams are used for

the technical debt estimation. In the next step, the technical debt items are to be analyzed

and prioritized. Based on these insights, a decision is required. In case the technical debt

item is pivoted, the validated learnings are used for the next instances of the cause and/or

effect analysis. In case the technical debt item is preserved, the validated causes, effects

and the backlog goe into the decomposition that derives technical debt User Stories that

are used as input for the development cycle.

Development Cycle. In the development cycle (see Figure 3), we added a continuous

phase for technical debt management that deals with the technical debt causes and effects,

as well as with the technical debt backlog. Further, we propose to introduce a quality gate

before launching the single feature MVP. Continuous integration should be extended by

continuous improvement and continuous delivery should also integrate a continuous

maintenance aspect.

5 Discussion and Conclusion

Based on a literature review, we propose an extended version of the Entrepreneurial

Software Engineering model to help startups avoid technical debt. By putting special

emphasis on the prevention, identification and management of technical debt items in early

stage startups, we hope startups can reduce the risk of unplanned difficulties introduced

by unintentionally accepting technical debt. However, the model itself is a theoretical

construct that has—in its extended version—not yet been validated in industry. Either

expert interviews or case studies should be conducted to evaluate the applicability and

usefulness of the proposed model, as well as the benefits regarding the prevention of

technical debt in startups.

However, as of now, by construction, the extended version of the Entrepreneurial Software

Engineering model provides a guideline to integrate technical debt management in early

stage startups. In a next step, a case study comparable to the validation of the initial

How to Mitigate Technical Debt in Startups 189

Entrepreneurial Software Engineering model as presented by Brunner et al. [BMK21]

should be conducted to evaluate the feasibility of the technical debt integration.

Fig. 2: Technical Debt Categorization and Prioritization included in the Entrepreneurial Software

Engineering Model [BMK21]. Changes are highlighted in blue.

190 Jil Klünder et al.

Fig. 3: Development phase of the Entrepreneurial Software Engineering Model [BMK21]

extended by technical debt. Changes are highlighted in blue.

6 References

[AH23] Abrahamsson, V.; Holmqvist, V.: Technical Debt in Swedish Tech Startups: Uncovering

its Emergence, and Management Processes, Master Thesis, KTH Royal Institute of

Technology, Stockholm, Sweden, 2023.

[Al16] Alves, N. S. et al.: Identification and management of technical debt: A systematic mapping

study. Information and Software Technology 70, pp. 100–121, 2016.

[Av16] Avgeriou, P. et al.: Managing technical debt in software engineering (dagstuhl seminar

16162). Dagstuhl reports 6 (4), pp. 110–138, 2016.

[BMK21] Brunner, D.; Münch, J.; Kuhrmann, M.: Entrepreneurial software engineering: towards a

hybrid development method for early-stage startups. WI-MAW-Rundbrief 27 (1), pp. 5–

15, 2021.

[BVG21] Bogner, J.; Verdecchia, R.; Gerostathopoulos, I.: Characterizing technical debt and

antipatterns in AI-based systems: A systematic mapping study. In: 2021 IEEE/ACM

International Conference on Technical Debt (TechDebt). IEEE, pp. 64–73, 2021.

[Fo09] Fowler, M.: Technical Debt Quadrant, [online] last access: June 30. 2025. URL:

https://martinfowler.com/bliki/TechnicalDebtQuadrant.html, 2009.

How to Mitigate Technical Debt in Startups 191

[Fr20] Freire, S. et al.: Actions and impediments for technical debt prevention: results from a

global family of industrial surveys. In: Proceedings of the 35th Annual ACM Symposium

on Applied Computing. Pp. 1548–1555, 2020.

[Go23] Gomes, F. et al.: Investigating the point of view of project management practitioners on

technical debt-a study on stack exchange. Journal of Software Engineering Research and

Development 11 (1), pp. 12–1, 2023.

[Gr14] Griffith, I. et al.: A simulation study of practical methods for technical debt management

in agile software development. In: Proceedings of the Winter Simulation Conference 2014.

IEEE, pp. 1014–1025, 2014.

[GSS16] Guo, Y.; Spínola, R. O.; Seaman, C.: Exploring the costs of technical debt management–

a case study. Empirical Software Engineering 21, pp. 159–182, 2016.

[He24] Heintz, F.: Avoiding technical debt in startups when developing software, Master Thesis,

Leibniz University Hannover, Germany, 2024.

[HKV16] Hokkanen, L.; Kuusinen, K.; Väänänen, K.: Minimum viable user experience: A

framework for supporting product design in startups. In: Agile Processes, in Software

Engineering, and Extreme Programming: 17th International Conference, XP 2016,

Edinburgh, UK, May 24-27, 2016, Proceedings 17. Springer, pp. 66–78, 2016.

[Ki10] Kitchenham, B. et al.: Systematic literature reviews in software engineering–a tertiary

study. Information and software technology 52 (8), pp. 792–805, 2010.

[KL10] Ktata, O.; Lévesque, G.: Designing and Implementing a Measurement Program for Scrum

Teams: What do agile developers really need and want? In: Proceedings of the Third C*

Conference on Computer Science and Software Engineering. Pp. 101–107, 2010.

[KMK22] Kuhrmann, M.; Münch, J.; Klünder, J.: Hacking or engineering? Towards an extended

entrepreneurial software engineering model. In: Proceedings of the International Confer-

ence on Software and System Processes and International Conference on Global Software

Engineering. Pp. 66–76, 2022.

[KSF20] Karras, O.; Schneider, K.; Fricker, S. A.: Representing software project vision by means

of video: a quality model for vision videos. journal of Systems and Software 162, p.

110479, 2020.

[KVG22] Kozanidis, N.; Verdecchia, R.; Guzmán, E.: Asking about technical debt: Characteristics

and automatic identification of technical debt questions on stack overflow. In: Proceedings

of the 16th ACM/IEEE International Symposium on Empirical Software Engineering and

Measurement. Pp. 45–56, 2022.

[LAL15] Li, Z.; Avgeriou, P.; Liang, P.: A systematic mapping study on technical debt and its

management. Journal of Systems and Software 101, pp. 193–220, 2015.

[MBB16] Martini, A.; Besker, T.; Bosch, J.: The introduction of technical debt tracking in large

companies. In: 2016 23rd Asia-Pacific Software Engineering Conference (APSEC). IEEE,

pp. 161–168, 2016.

192 Jil Klünder et al.

[MTR20] Mandić, V.; Taušan, N.; Ramač, R.: The prevalence of the technical debt concept in

serbian it industry: Results of a national-wide survey. In: Proceedings of the 3rd

international conference on technical debt. Pp. 77–86, 2020.

[Ri19] Rios, N. et al.: Supporting analysis of technical debt causes and effects with cross-

company probabilistic cause-effect diagrams. In: 2019 IEEE/ACM International

Conference on Technical Debt (TechDebt). IEEE, pp. 3–12, 2019.

[Ri20] Rios, N. et al.: The practitioners’ point of view on the concept of technical debt and its

causes and consequences: a design for a global family of industrial surveys and its first

results from Brazil. Empirical Software Engineering 25, pp. 3216–3287, 2020.

[RMS18] Rios, N.; de Mendonça Neto, M. G.; Spínola, R. O.: A tertiary study on technical debt:

Types, management strategies, research trends, and base information for practitioners.

Information and Software Technology 102, pp. 117–145, 2018.

[Sh13] Shull, F. et al.: Technical debt: Showing the way for better transfer of empirical results.

Perspectives on the future of software engineering: essays in honor of Dieter Rombach,

pp. 179–190, 2013.

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 193

Digitale Kompetenz im Projektmanagement: Ein

Kompetenzstrukturmodell für das digital strukturierte

Projektmanagement

Jessica Nagel 1

Abstract: Die digitale Transformation verändert das Projektmanagement grundlegend. Diese Studie

untersucht, welche digitalen Kompetenzen Projektmanager*innen im Kontext externer IT- und

Unternehmensberatung benötigen. Auf Basis qualitativer Daten wurden ein

Kompetenzstrukturmodell entwickelt und sieben zentrale Kompetenzbereiche identifiziert, u.a.

digitale Führung, Wissensmanagement und Toolkompetenz. Das Modell bietet eine Grundlage für

die gezielte Kompetenzentwicklung in der Projektarbeit.

Keywords: Digitale Kompetenzen, Projektmanagement, digitale Transformation, IT-Beratung,

Kompetenzmodell, virtuelle Teams, Wissensmanagement

1 Einleitung

Die Digitalisierung führt zu tiefgreifenden Veränderungen in Wirtschaft und Gesellschaft.

Unternehmen stehen unter dem Druck, sich durch digitale Technologien wettbewerbsfähig

zu halten und gleichzeitig den steigenden Anforderungen an Flexibilität und

Geschwindigkeit gerecht zu werden. Um wettbewerbsfähig zu bleiben, müssen sie digitale

Technologien gezielt einsetzen und zugleich den steigenden Anforderungen an Flexibilität

und Geschwindigkeit gerecht werden. Projektmanagement ist eine Schlüsselstrategie, um

diesen Herausforderungen zu begegnen. Dabei kommt den Kompetenzen von

Projektmanager*innen eine entscheidende Rolle zu.

Diese Arbeit untersucht, welche Kompetenzen im digital strukturierten

Projektmanagement notwendig sind, und entwickelt ein Kompetenzstrukturmodell, das

die Auswirkungen der digitalen Transformation auf die Kompetenzanforderungen

beschreibt.

1 Jessica Nagel https://orcid.org/0009-0002-1046-6464

194 Jessica Nagel

2 Kompetenzen und Digitalisierung

2.1 Definition und Modellierung von Kompetenzen

Der Kompetenzbegriff ist nicht einheitlich definiert, sondern variiert je nach

wissenschaftlicher Disziplin und Anwendungsbereich. In dieser Arbeit wird ein

Verständnis von Kompetenz zugrunde gelegt, das in der Wirtschaftspädagogik verbreitet

ist. Es beschreibt Kompetenz als die Fähigkeit, Wissen, kognitive Fähigkeiten und

Fertigkeiten zur Bewältigung sowohl bekannter als auch neuer Herausforderungen in

variablen Kontexten anzuwenden [Wei01]. Dieses domänenspezifische Verständnis

erlaubt eine differenzierte Betrachtung beruflicher Anforderungen und bildet eine

fundierte Grundlage für die Entwicklung praxisrelevanter Kompetenzmodelle im

Projektmanagement.

In der Wirtschaftspädagogik wird Kompetenz häufig in vier Dimensionen gegliedert:

Fach-, Methoden-, Sozial- und Selbstkompetenz. Diese Struktur erlaubt es, sowohl

technische als auch kommunikative und reflexive Anforderungen systematisch zu

erfassen. Sie hat sich insbesondere in der beruflichen Bildung als analytisch hilfreich

erwiesen und dient auch in dieser Arbeit als Strukturierungsrahmen für die Ableitung

digitaler Kompetenzen im Projektmanagement [Erp08]. Kompetenzmodelle bieten dabei

eine strukturierte Beschreibung der notwendigen Fähigkeiten für spezifische

Tätigkeitsfelder. Man unterscheidet zwischen Kompetenzstrukturmodellen, die

verschiedene Kompetenzdimensionen definieren, und Kompetenzniveaumodellen, die die

Beherrschung einer Kompetenzstufe messen.

2.2 Digitale Transformation und ihre Auswirkungen auf das Projektmanagement

Projektmanagement ist heute in vielen Branchen etabliert und wird zunehmend durch

digitale Technologien geprägt. Während klassische Methoden auf strukturierte Planung

setzen, sind agile Ansätze stärker iterativ und anpassungsfähig. Die externe IT- und

Unternehmensberatung sieht sich mit Herausforderungen wie hybriden Projektstrukturen,

virtuellen Teams und der Notwendigkeit einer stetigen Kompetenzentwicklung

konfrontiert. Die zunehmende Integration digitaler Technologien verändert dabei nicht nur

Methoden, sondern auch Rollenbilder im Projektmanagement [HRR22].

Die digitale Transformation beeinflusst nicht nur Unternehmensprozesse, sondern

verändert auch Arbeitsweisen und die Anforderungen an Fachkräfte.

Projektmanager*innen müssen mit digitalen Tools umgehen, Daten analysieren und

Automatisierungspotenziale nutzen. Gleichzeitig erfordert die zunehmende

Virtualisierung der Zusammenarbeit eine ausgeprägte Kommunikationsfähigkeit und

digitale Führungskompetenz. Die Bewältigung der steigenden Informationsflut sowie die

kritische Reflexion digitaler Inhalte stellen weitere Herausforderungen dar. Die Relevanz

digitaler Kompetenzen für den Projekterfolg wurde international bereits betont [MM21].

Dabei fehlt es an einem einheitlichen Begriffsverständnis digitaler Kompetenz, obwohl

politisch relevante Modelle wie DigComp auf grundlegenden Arbeiten basieren [Fer12].

Bestehende Kompetenzmodelle wie etwa das von Marhraoui [Mar23] greifen zwar

Digitale Kompetenz im Projektmanagement 195

digitale Aspekte auf, fokussieren jedoch nicht auf projektbezogene Anforderungen.

Neuere Studien fordern eine stärkere Integration digitaler Future Skills in

Projektmanagementmodelle [MKNS24].

3 Forschungsmethodik

Die Studie basiert auf einer explorativen, qualitativen Untersuchung. Ziel war es, die im

digitalen Projektmanagement erforderlichen Kompetenzen systematisch zu erfassen und

zu strukturieren. Dazu wurde ein mehrstufiges Vorgehen gewählt, das sich in drei Phasen

gliedert: systematische Literaturrecherche, Fokusgruppen mit erfahrenen

Projektmanager*innen sowie kommunikative Validierung durch Expert*innen.

Die Literaturrecherche diente der Identifikation bestehender Kompetenzmodelle sowie

theoretischer Bezugspunkte im Kontext digitaler Kompetenzen und Projektmanagement.

Darauf aufbauend wurden Fokusgruppen mit Praktiker*innen aus der IT- und

Unternehmensberatung durchgeführt. In moderierten Gruppendiskussionen wurden reale

Handlungsanforderungen und Kompetenzerwartungen thematisiert.

Zur Validierung der Ergebnisse wurde eine dritte Phase implementiert: In

kommunikativen Validierungsworkshops wurden die abgeleiteten

Kompetenzdimensionen kritisch diskutiert, ergänzt und priorisiert.

Die qualitative Inhaltsanalyse erfolgte nach dem Vorgehen nach Kuckartz [Kuc18]. Die

Auswertung wurde softwaregestützt mit MAXQDA durchgeführt. Zur Sicherung der Güte

wurden Kriterien wie Transparenz, intersubjektive Nachvollziehbarkeit und theoretische

Sättigung berücksichtigt.

4 Veränderungen durch digitale Transformation im

Projektmanagement

Die empirische Untersuchung zeigt, dass sich die grundlegenden Kernkompetenzen im

Projektmanagement durch die digitale Transformation nicht vollständig verändern, jedoch

deutlich erweitern. Insbesondere entstehen neue Anforderungen in technologischer,

sozialer und informationeller Hinsicht.

4.1 Technologische Kompetenz als Basis

Projektmanager*innen müssen digitale Technologien nicht nur bedienen, sondern auch

strategisch in ihre Arbeit integrieren. Dies umfasst die gezielte Auswahl und Nutzung

digitaler Projektmanagement-Tools sowie ein grundlegendes Verständnis für

Automatisierung, Datenanalyse und KI-gestützte Entscheidungsprozesse. Die Integration

neuer Technologien in bestehende Strukturen stellt eine weitere wesentliche

Herausforderung dar.

196 Jessica Nagel

4.2 Soziale Kompetenz in virtuellen Teams

Die Führung verteilter Teams erfordert spezifische Fähigkeiten, um Motivation und

Teamgeist auch im digitalen Raum zu erhalten. Ein vertrauensvolles Arbeitsklima muss

aufgebaut und gepflegt werden, während gleichzeitig eine klare, zielgerichtete und

kanalgerechte Kommunikation sicherzustellen ist. Hinzu kommt das Erfordernis eines

effektiven Konfliktmanagements, um Missverständnisse oder kulturelle Unterschiede in

virtuellen Teams erfolgreich zu überwinden.

4.3 Informations- und Wissensmanagement

Die zunehmende Datenflut erfordert eine differenzierte Herangehensweise an

Informationsmanagement. Projektmanager*innen müssen digitale Quellen kritisch

bewerten und effizient filtern, um relevante Informationen strukturiert und nachhaltig zu

nutzen. Gleichzeitig gewinnt kollaboratives Wissensmanagement an Bedeutung, um

gemeinsames Lernen und eine kontinuierliche Weiterentwicklung innerhalb des Teams zu

fördern.

5 Kompetenzstrukturmodell

Basierend auf den qualitativen Ergebnissen wurde ein Kompetenzstrukturmodell

entwickelt, das sieben zentrale Kompetenzbereiche im digital strukturierten

Projektmanagement beschreibt. Diese Bereiche bündeln die Anforderungen, die sich aus

der digitalen Transformation ergeben, und dienen als Grundlage für die Entwicklung

entsprechender Lern- und Entwicklungsangebote.

Die sieben Kompetenzbereiche sind wie folgt strukturiert:

• Informations- und Datenmanagement

− Datenanalyse und digitale Entscheidungsfindung

− Kritische Reflexion digitaler Informationen

• Virtuelle Zusammenarbeit

− Interkulturelle Zusammenarbeit in virtuellen Teams

− Digitales Konfliktmanagement

• Digitale Kommunikation

− Digitale Führung und Teammotivation

− Virtuelle Moderation und Facilitation

• Erstellung digitaler Inhalte

− Wissensmanagement und kontinuierliches Lernen

• Ethik, Verantwortung und Sicherheit

Digitale Kompetenz im Projektmanagement 197

− Digitale Ethik und Datenschutzbewusstsein

− IT-Sicherheitsbewusstsein

• Digitales Management

− Strukturierung und Priorisierung von Informationen

• Technische Kompetenz

− Nutzung und Auswahl digitaler Projektmanagement-Tools

− Anwendung agiler und hybrider Projektmanagementmethoden

Das Modell verdeutlicht, dass digitale Kompetenzen weit über reine Technikbeherrschung

hinausgehen. Vielmehr geht es um die Verbindung von technischen, sozialen, reflexiven

und ethischen Fähigkeiten, um digitale Projekte erfolgreich zu gestalten.

6 Praxisimplikationen und zukünftige Entwicklungen

Die Ergebnisse der Studie zeigen deutlich, dass Unternehmen die gezielte Förderung

digitaler Kompetenzen bei Projektmanager*innen systematisch angehen sollten. Dazu

gehören Weiterbildungsprogramme, die sowohl technische Fähigkeiten als auch soziale

und reflexive Kompetenzen adressieren.

Besonders im Kontext der IT- und Unternehmensberatung ist es entscheidend, aktuelle

technologische Entwicklungen wie Künstliche Intelligenz, kollaborative Plattformen oder

digitale Entscheidungsunterstützung kontinuierlich in Kompetenzprofile zu integrieren.

Die regelmäßige Aktualisierung dieser Profile sowie deren Integration in

Personalentwicklungsmaßnahmen ist ein wesentlicher Schritt, um zukunftsfähiges

Projektmanagement zu gewährleisten.

Darüber hinaus sollten Unternehmen eine digital geprägte Organisationskultur etablieren,

die digitale Zusammenarbeit, agiles Denken und verantwortungsbewussten Umgang mit

Daten strukturell verankert. Führungskräfte spielen dabei eine Schlüsselrolle als

Impulsgeber und Vorbilder für digitale Kompetenzentwicklung.

7 Fazit

Die digitale Transformation verändert das Projektmanagement nicht nur durch neue

Technologien, sondern vor allem durch veränderte Anforderungen an Führung,

Kommunikation, Kollaboration und Wissensmanagement. Digitale Kompetenzen gelten

als Schlüsselfaktor für den Projekterfolg in digitalen Umgebungen [RGL21]. Die

vorliegende Studie zeigt, dass digitale Kompetenzen vielfältig, kontextabhängig und eng

mit sozialen und reflexiven Fähigkeiten verknüpft sind [Nag2024].

Das entwickelte Kompetenzstrukturmodell bietet eine fundierte Grundlage für die gezielte

Qualifizierung von Projektmanager*innen in digital geprägten Projektumgebungen. Es

198 Jessica Nagel

ermöglicht Unternehmen, Bildungseinrichtungen und Zertifizierungsstellen, konkrete

Handlungsfelder zu identifizieren und zukunftsorientierte Entwicklungspfade zu

gestalten.

Zukünftige Forschung sollte die Übertragbarkeit des Modells auf andere Branchen und

Organisationsformen untersuchen und quantitative Validierungen zur Weiterentwicklung

des Modells durchführen. Auch die Integration neuer technologischer Trends – etwa im

Bereich künstlicher Intelligenz – bietet Potenzial für die Weiterentwicklung digitaler

Kompetenzprofile.

Literaturverzeichnis

[Erp08] Erpenbeck, J.; Heyse, V.: Kompetenztraining. Strategien, Methoden und Bausteine für

die Kompetenzentwicklung. 5. Aufl., Schäffer-Poeschel, Stuttgart, 2008.

[Fer12] Ferrari, A.: Digital Competence in Practice: An Analysis of Frameworks. JRC Technical

Reports, European Commission, 2012.

[HRR22] Harwardt, M.; Reuschenbach, T.; Reuschenbach, M.: Projektmanagement in der

digitalen Transformation. In: HMD Praxis der Wirtschaftsinformatik, 59, 2022, S. 1114–

1131.

[Kuc18] Kuckartz, U.: Qualitative Inhaltsanalyse. Methoden, Praxis, Computerunterstützung. 4.

Aufl., Beltz Juventa, 2018.

[Mar23] Marhraoui, A.: Digitale Kompetenzen im Projektmanagement – Eine Analyse

bestehender Kompetenzmodelle. In: Zeitschrift für Projektmanagement, 39(2), 2023, S.

45–53.

[MM21] Marnewick, C.; Marnewick, A.: Digital Competency Requirements for Project

Managers. In: Int. J. of Managing Projects in Business, 14(5), 2021, S. 1027–1042.

[MKNS24] Müller, R.; Konzag, C.; Nielsen, J.; Sandholt, H.: Future Skills for Project Management

– Integrating Digital Literacy. In: Int. J. of Project Management, 2024.

[Nag24] Nagel, J.: Digital Literacy im Projektmanagement. Entwicklung eines

Kompetenzstrukturmodells für das digital strukturierte Projektmanagement. Springer

VS, Wiesbaden, 2024.

[RGL21] Ribeiro, F.; Gomes, R.; Lopes, A.: The Role of Digital Competencies in Project Success.

In: Procedia Computer Science, 181, 2021, S. 865–872.

[Wei01] Weinert, F.E.: Concept of Competence: A Conceptual Clarification. In: Rychen, D.S.;

Salganik, L.H. (Hrsg.): Defining and Selecting Key Competencies. Hogrefe and Huber

Publishers, Seattle, 2001, S. 45–66.

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 199

Transformational Skills für die digitale und nachhaltige

Transformation: Innere Entwicklung als Schlüssel zur

Veränderung von (Projektmanagement-) Kultur

Kendra Pöhlmann 1 und Julia Hodapp2

Abstract: Die digitale Transformation ist mehr als ein technologischer Wandel – sie fordert ein

tiefgreifendes Umdenken auf individueller, kultureller und organisationaler Ebene. Der Beitrag

argumentiert, dass klassische und agile Methoden allein nicht ausreichen, um den aktuellen

Herausforderungen in einer BANI-Umwelt zu begegnen. Vielmehr braucht es ein erweitertes

Kompetenzverständnis, die sogenannten Transformational Skills. Inspiriert durch Konzepte wie die

Inner Development Goals, Bildung für nachhaltige Entwicklung (BNE) und das Rounder Sense of

Purpose-Modell, werden neue Schlüsselkompetenzen vorgestellt, die Projektarbeit und Führung

nachhaltig verändern können. Der Beitrag zeigt, wie diese Kompetenzen im post-agilen

Projektmanagement konkret verankert werden können – als strategische Ressourcen zur Förderung

von Resilienz, Sinnorientierung und kulturellem Wandel. Persönlichkeitsentwicklung wird dabei

nicht als privates Anliegen, sondern als zentraler Hebel für zukunftsfähige

Organisationsentwicklung verstanden, für die klassische und agile Projektmanagementansätze nicht

mehr ausreichend sind.

Keywords: Digitale Transformation, Transformational Skills, Reflexionskompetenz, Emotionale

Selbstregulation, Post-agiles Arbeiten

1 Einleitung

Die digitale Transformation fordert Organisationen, Führungskräfte und Mitarbeitende

auf vielfältige Weise heraus. Dabei geht es längst nicht mehr nur um technologische

Innovationen, Prozessoptimierung und deren Umsetzung in Projekten– vielmehr vollzieht

sich ein tiefgreifender kultureller Wandel, der auch individuelle Entwicklung und neue

Formen des Miteinanders erfordert.

In einem dynamischen, komplexen und von Megatrends wie Digitalisierung und

Nachhaltigkeit geprägtem Umfeld stoßen sowohl klassische sowie auch agile

Projektmanagementansätze zunehmend an ihre Grenzen. Projektarbeit, agile Methoden

und digitale Tools reichen allein nicht mehr aus, um Orientierung, Stabilität und

Nachhaltigkeit zu erzeugen. Vielmehr wird deutlich, dass es eine erweiterte Perspektive

auf Kompetenzen, innere Haltung und Werte bedarf, um die digitale Transformation zu

erreichen und sie verantwortungsvoll zu gestalten.

1 OTH Regensburg, Fakultät Business and Management, Seybothstr. 2 93053 Regensburg,

kendra.poehlmann@oth-regensburg.de, https://orcid.org/0000-0002-1234-9002

2 TH Köln und HS Koblenz, julia.hodapp@hotmail.de, https://orcid.org/0000-0002-6215-6903

200 Kendra Pöhlmann und Julia Hodapp

Mit der digitalen Transformation gehen fundamentale Veränderungen in der Arbeitsweise

von Mitarbeitenden und in der Struktur von Organisationen einher. Am Beispiel der

Einführung von elektronischen Akten soll dies näher aufgezeigt werden. Projekte der

digitalen Transformation zeichnen sich nicht nur durch ihre Einzigartigkeit aus. Jedes

Projekt ist zudem zeitlich begrenzt. Eine besondere Komplexität ergibt sich durch die

erforderlich gewordene Parallelität von Projekten. In einem dynamischen und

zeitdringlichen Umfeld müssen Projekte der digitalen Transformation notgedrungen

parallel und zeitgleich durchgeführt werden. Zusätzlich stehen viele Projekte in einer

inhaltlichen und zeitlichen Abhängigkeit voneinander, was zu einer deutlich erhöhten

Komplexität und Verdichtung von Inhalten führt. Die Projektarbeit für Projektleitende und

Mitarbeitende stellt daher ganz andere Anforderungen an diese, als bei der klassischen

Projektarbeit der Fall ist.

Der vorliegende Beitrag plädiert für eine neue, erweiterte Perspektive, die unter den

sogenannte Transformational Skills, vor allem Selbstkompetenz und Regulationsfähigkeit

in den Vordergrund rücken und zu einem weiteren essenziellen Bestandteil von

Projektmanagementkompetenzen geworden sind. Er zeigt auf, warum diese Dimensionen

nicht nur „nice to have“, sondern zentral für eine resiliente, lernfähige und nachhaltige

Organisation sind, um dort Projekte erfolgreich umsetzen zu können. Der Fokus liegt auf

Projektleitungen und Mitarbeitenden, kann aber ebenso auch auf Projekt-

Stakeholder:innen angewandt werden.

Die englische Übersetzung - Skills – umfasst zum einen eine Fortsetzung des

Kompetenzbegriffs [Eh20] und zum anderen einen Fokus auf Handlungsorientierung und

-fähigkeit, der in Abhängigkeit von persönlichen Werten, Einstellungen, Meinungen und

Emotionen steht und immer kontextabhängig ist [ER07]. Daher die Spezifizierung auf

Transformational Skills.

2 Transformational Skills

Transformation ist multilateral und mehrdimensional. Deswegen geht es – zwar auch aber

nicht ausschließlich - um digitale Transformation. Vielmehr geht es um ihr

Zusammenspiel mit nachhaltiger Transformation. Was beiden Strömungen gemein ist, ist

ihre Komplexität und ihr Disruptionspotenzial, was Organisationen auf struktureller,

kultureller und individueller Ebene herausfordert. Während in der digitalen

Transformation häufig technologische Fähigkeiten wie Data Literacy oder der Umgang

mit KI in den Vordergrund gerückt werden, gewinnen zunehmend auch Kompetenzen an

Relevanz, die soziale, ethische und emotionale Dimensionen des Wandels adressieren.

Diese lassen sich als Transformational Skills bezeichnen.

Die Impulse hierfür kommen dabei aus unterschiedlichen Disziplinen: Die Bildung für

nachhaltige Entwicklung (BNE) hat frühzeitig betont, dass es für zukunftsfähiges Handeln

Kompetenzen wie systemisches, vorausschauendes sowie kritisches Denken, Normative

und Strategische Kompetenz, Fähigkeit zur Kooperation und Problemlösung, sowie auch

Selbstkompetenz und Emotionsregulierung braucht [BLB24], [Br21], [Un17]. Ein

Transformational Skills für die digitale und nachhaltige Transformation 201

ähnliches Kompetenzset umfasst das Rounder Sense of Purpose Modell. Dieses verweist

auf die Notwendigkeit, sowohl kognitive als auch ethische und emotionale Kompetenzen

in Bildungs- und Transformationsprozesse zu integrieren [Va19]. Das internationale

Framework der Inner Development Goals (IDGs) [An23] ergänzt diese Perspektive um

die Dimension der inneren Entwicklung: Fähigkeiten wie Selbstreflexion, Empathie,

Authentizität, Demut oder Mut werden als zentrale Voraussetzungen verstanden, die

notwendig sind, um die 17 Nachhaltigkeitsziele (SDGs) überhaupt realisieren zu können3.

Die Quintessenz aus diesen Impulsen umfasst tiefgehende und weitreichende

Reflexionskompetenz, die ermöglicht, Symptomen auf den Grund zu gehen, Kausalitäten,

Prägungen und Muster aufzudecken, um zu deren Veränderung neue Wege einzuschlagen.

Die Fähigkeit Ambivalenzen und Unbequemes auszuhalten, sowie neue Brücken zu

schlagen zwischen vermeintlichen Widersprüchen, zwischen Alt und Neu, Tradition und

Innovation, Wasserfall und Agilität, Vulnerabilität und Widerstandsfähigkeit.

Am Beispiel der Einführung von digitaler Aktenführung lässt sich dies einfach

verdeutlichen. Neben einer „klassischen“ Softwareimplementierung gilt es zunächst zu

definieren, wie zukünftige Prozesse aussehen können. Optimierte digitale Prozesse sollen

neben der Vereinfachung, Einsparung von überflüssigen Arbeitsschritten sowie deren

intuitive Verkürzung, zugleich möglichst automatisiert ablaufen. Dabei soll einem

bewussten und nachhaltigen Umgang mit Ressourcen Sorge getragen werden. Bislang

tradierte Arbeitsweisen stehen auf dem Prüfstand und müssen mitunter abstrakt im

Greenfield-Ansatz neukonzipiert und abstrakt neu gedacht werden. Dies kann Sorgen.

Ängste und Widerstände von Betroffenen zu Tage bringen. Die prozessuale

Neuausrichtung bedarf viel Kommunikation und Selbstreflexion bei allen Beteiligten. Sie

vollzieht sich häufig in einem bereits verdichteten Arbeitsumfeld. In einer Linien-

/Projektstruktur können prozessuale Umstrukturierungen auch zufolge haben, dass

Tätigkeiten von Linienvorgesetzten betroffen sind, was für alle Beteiligten ein mögliches

Konfliktpotential bietet.

Für ein post-agiles Projektmanagement lassen sich folglich Fähigkeiten wie

Ambiguitätstoleranz, Komplexitätsbewältigung, Kontextualisierung, Begegnung von

Widerständen sowie Ressourcenschutz und Suffizienz herausarbeiten. Diese müssen nun

konkret in ein transformatives Projektmanagement überführt werden. Transformativ ist

Projektmanagement immer dann, wenn es sich im weitesten Sinne dem Konzept der

Nachhaltigkeit verschreibt oder positiv zu nachhaltiger Entwicklung beiträgt [SMA19].

Ein anderer Indikator ist, wenn sich der Fokus der Kontrolle von Zeit, Qualität oder

Budget hin zu sozialem, ökologischem oder ökonomischem Impact verschiebt [SS14].

Eine zentrale und wichtige Facette, die in verschiedenen Transformational Skills zum

Tragen kommt, ist die emotionale Regulationsfähigkeit – unabhängig davon, ob sie als

neurologische Selbstregulation, Reflexionsfähigkeit oder Achtsamkeit bezeichnet wird.

Gemeint ist die Fähigkeit, sich in herausfordernden, oft ambivalenten oder unsicheren

Projektsituationen resilient zu zeigen, differenziert zu reagieren und bewusste

Entscheidungen zu treffen. Im breiteren Verständnis wird (Selbst-)Regulationsfähigkeit

3 Bei diesem exemplarischen Schlaglicht handelt es sich weder um eine abschließende noch um eine

vollumfängliche Liste, sondern es soll lediglich als Impuls und Denkanstoß dienen.

202 Kendra Pöhlmann und Julia Hodapp

als Umgang mit Gefühlen, Stimmungen und Emotionen und deren Reaktion darauf

beschrieben [Eh20] oder auch als Ziel-orientiertes Verhalten, das mit Feedback-Schleifen

arbeitet und eine Nähe zum Begriff der Selbstkontrolle aufweist [Ba04].

Reflexives Agieren, multi-dimensionale Perspektivwechsel und Empathie stellen im post-

agilen Projektmanagement die zentralen Kompetenzen dar, um komplexe Projekte

erfolgreich steuern und umsetzen zu können. Für Projektleitende bedeutet dies, sich noch

stärker in einem Umfeld von Ambivalenz zu bewegen und Entscheidungsfindungen in

einem sehr dynamischen Informationslage mit vielen Variablen vorzunehmen.

Insbesondere im Projektmanagement von Digitalisierungsprojekten kann eine

erfolgreiche Umsetzung nur in einer hybriden Form des agilen Projektmanagements

gelingen, um Arbeitspakete trotz einer Vielzahl von abhängigen Parametern erfolgreich

abschließen zu können. In diesem Projektkonstellationen bewegen sich die Akteur:innen

in einem stetigen Spannungsfeld von Unberechenbarkeiten und Abhängigkeiten, in dem

sie transformationales Skills benötigen.

Die oben aufgeführten Fähigkeiten bilden daher das Fundament für nachhaltige

Veränderungsprozesse – gerade dort, wo klassische Projektmethoden an ihre Grenzen

stoßen. In einem transformativ verstandenen Projektmanagement, das über die rein

operative Zielverfolgung hinaus auch kulturellen Wandel mitgestaltet, zählt die

emotionale Selbstregulation zu einer Schlüsselkompetenz, da sie Unsicherheiten aushalten

und Widerstände auflösen kann. Sie kann gezielt gestärkt werden, indem man sich aus

einem vielfältigen Methodenbaukasten bedient, der Elemente aus der Achtsamkeitspraxis,

Meditation sowie psychologisch-neurowissenschaftlich fundierten Übungen enthält.

Diese Werkzeuge schaffen mehr als kurzfristige Entspannung: Sie fördern eine Haltung

der bewussten Präsenz, der Selbstführung und der Resonanz im Team. So wird emotionale

Regulationsfähigkeit nicht nur zur individuellen Ressource, sondern wirkt als kulturelles

Vehikel, das die Grundlage für vertrauensvolle Zusammenarbeit, innovative

Lösungsfindung und resiliente Projektkultur schafft. Transformatives Projektmanagement

bedeutet damit auch, emotionale Intelligenz und Selbstregulation systematisch zu

integrieren – sowohl als Ergänzung, als auch als strategischer Erfolgsfaktor.

Es braucht folglich mehr als Schulungen in Tools oder Prozessen, sondern einen neuen

Fokus auf die Interaktion und die Introspektion. Räume und Konzepte sind erforderlich,

in denen sowohl Mitarbeitende als insbesondere auch Führungskräfte gleichermaßen

lernen, was sie tun, sondern auch warum und wie. Transformational Skills ermöglichen

es, Unsicherheit und Ambiguitäten auszuhalten, Widersprüche zu integrieren und Sinn in

der Veränderung zu finden. Dabei steht diese Kompetenzentwicklung selbstverständlich

nicht allein. Vielmehr ist sie hochgradig vernetzt in die Unternehmens- oder

Organisations-Kulturentwicklung und somit auch in das Projektmanagement und deren

methodische Verankerung.

Transformational Skills für die digitale und nachhaltige Transformation 203

3 Berücksichtigung von Transformational Skills im post-agilen

Projektmanagement-Kontext

Viele der Grundgedanken des ursprünglichen Scrum-Manifests [SS20] tragen bereits in

ihrer Reinform achtsame Elemente in sich – nicht nur auf methodischer, sondern auch auf

kulturell-philosophischer Ebene. Mit einem hohen Fokus auf Feedback, Kommunikation

und das Einbeziehen der Nutzer:innenperspektive greift das agile Arbeiten dabei Werte

wie Respekt, Offenheit und Fokus auf ebenso wie ein Menschenbild, das von

Selbstwirksamkeit, Verantwortungsbereitschaft und Reflexionsfähigkeit geprägt ist. Im

Projektmanagementkontext bedeutet dies bedürfnisorientiert Mitarbeitende einzubinden

und Perspektivwechsel vorzunehmen, Veränderung als Chance zu begreifen und

Verantwortung für ihre Beiträge im Gesamtprozess zu übernehmen. Gerade in Scrum-

Formaten wie der Retrospektive wird dies besonders spürbar: Es wird bewusst Raum für

Selbstwahrnehmung, Zwischenmenschlichkeit und Systemreflexion geschaffen. Dieser

Raum erlaubt es, gewohnte Denkpfade zu hinterfragen, emotionale Reaktionen

einzuordnen und bewusstere Entscheidungen zu treffen. Genau hier überschneiden sich

die Prinzipien der Achtsamkeit mit den Zielen agiler Praktiken [Pö25].

In einem post-agilen Projektmanagement-Kontext [Ge23], der über Methodik hinaus in

Richtung Haltung und Kulturentwicklung denkt, gilt es daher, diese wertvollen Elemente

nicht nur zu bewahren, sondern aktiv weiterzuentwickeln und organisational zu verankern.

Das klassische Projektmanagement (Wasserfall) reicht an dieser Stelle nicht mehr aus, um

dynamische Projekte der digitalen Transformation umzusetzen. Das agile

Projektmanagement als methodische Weiterentwicklung bringt zwar die erforderliche

Agilität in einem dynamischen Veränderungsprozess mit, es greift jedoch zu kurz um die

Herausforderungen aufzugreifen, die sich durch die Projektarbeit in der digitalen

Transformation ergeben. Agil handeln zu können und Arbeitspakete ressourcenorientiert

abzuschließen ist weiterhin ein entscheidendes Moment in der erfolgreichen

Projektsteuerung. Es ist allerdings nicht mehr ausreichend, um hochkomplexe,

dynamische und parallel ablaufende Veränderungsprojekte erfolgreich zu steuern. Mit den

Projekten der digitalen Transformation geht zwingend auch ein Kulturwandel einher, der

anders methodisch aufgegriffen werden muss und für den das agile Projektmanagement

zu einseitig und zu kurz greift. Das Projektmanagement muss daher an dieser Stelle

weiterentwickelt werden, um auch die Komponente der dynamischen und hochkomplexen

Verdichtung von strukturverändernden Projekten angemessen Sorge zu tragen.

Am Beispiel der Einführung von digitaler Aktenführung eröffnet dieser Ansatz für

Mitarbeitende die Partizipation an der Ausgestaltung des zukünftigen Arbeitsplatzes. In

der Projektdurchführung sind Projektleitende und -mitarbeitende gleichermaßen von

externen und internen Abhängigkeiten betraut. Mit der prozessualen Optimierung bin zu

digitalen Soll-Prozessen gehen Grundsatzfragen und Konflikte einher.

Unterschriftenwege müssen hinterfragt und ggf. neu definiert werden. Die neue

Prozessführung und Rollendefinition erfordert mitunter eine Veränderung in der Macht-

und Informationsstruktur von Führungskräften, die zu Konflikten führen kann. Mit der

prozessorientierten Ausrichtung von eAkten werden klassische Linienstrukturen

aufgeweicht. Mitarbeitende, die bislang eher den eigenen Spezialbereich im Blick hatten,

204 Kendra Pöhlmann und Julia Hodapp

sehen sich nun der Herausforderungen gegenüber, den Blick auf das ‚große Ganze‘

richten. Dies verlangt von den Betroffenen ein hohes Maß an Selbstreflexion und

Kommunikationsfähigkeit. Mit einem kollaborativen Ansatz können Projektmitarbeitende

gemeinsam die erforderlichen Anforderungen erarbeiten und in der Prozessabfolge

sinnvoll verorten, auch wenn dies für einen andere Bereich vermeintlich Mehrarbeit mit

sich bringt. Das gemeinsame kollaborative Arbeiten an Projektinhalten ermöglicht (und

erfordert zugleich von) den Beteiligten eigenes Persönlichkeitswachstum in Form von

emotionaler Selbstregulation, Selbstreflexion und Resilienz. In einem besonders

dynamischen Projektumfeld wie in der digitalen Transformation ist es für alle Beteiligten

erforderlich die bestehenden Ambivalenzen auszuhalten und nebeneinander bestehen zu

lassen, und sich zugleich die erforderliche Offenheit und Kommunikationsfähigkeit zu

bewahren. Konflikte sind in der Projektarbeit allgegenwärtig. In Projekten der digitalen

Transformation verdichten sich die konfliktreichen Situationen sowohl quantitativ als

auch qualitativ. Die oben vorgestellten Formate greifen dies gezielt auf und ermöglichen

den (Selbst-)Diskurs und öffnen Raum für Reflexion. Während im agilen

Projektmanagement der Schwerpunkt auf Kommunikation und Feedback/Evaluation liegt,

erweitert das weiterentwickelte transformative Projektmanagement das agile Framework

um Selbstführung, emotionale Regulationsfähigkeit und Selbstreflexion.

Konkrete Praktiken wie z.B. Check-ins, Manual of Me, Rollenklärungen, Team-Manifeste

oder Round-Robin-Formate können helfen, diese Haltung im Projektalltag zu kultivieren.

Entscheidend ist dabei die Übertragbarkeit in den Alltag – etwa durch achtsam gestaltete

Meetings, durch eine Führung, die Authentizität und Verletzlichkeit zulässt, oder durch

eine Weiterbildungskultur, die Fehlerfreundlichkeit lebt [PH25].

Die bewusste Förderung dieser Kultur gleicht – im wahrsten Sinne – keinem Sprint,

stattdessen vielmehr einem Langstreckenlauf. Und dieser Lauf wird zunehmend

notwendig: In einer Welt, die sich im BANI-Zustand befindet – brüchig, ängstlich,

nichtlinear und unbegreiflich – suchen Menschen nach Halt, Klarheit und Orientierung.

Achtsamkeit und Empathie werden also in diesem Zusammenhang nicht zufällig

zunehmend als Standardstrategie zur Bewältigung empfohlen [Ma24]. Genau hier können

Transformational Skills ansetzen, die auf neurologischer Regulationsfähigkeit, Empathie

und achtsamen Umgang miteinander setzen.

Das Erkennen eigener Denkmuster, fördert Empathie im Umgang mit anderen und

eröffnet Handlungsspielräume jenseits automatisierter Reaktionen. Besonders in

Veränderungsprozessen, in denen Widerstand, Überforderung oder Verunsicherung

häufig auftreten, kann eine auf Reflexion und Introspektion fokussierte Grundhaltung

helfen, individuelle wie kollektive Resilienz zu stärken. Wer den Menschen in seiner

Ganzheit ernst nimmt, stärkt nicht nur persönliche Entwicklung, sondern gestaltet

gleichzeitig den Boden für nachhaltige, transformative Projektarbeit im digitalen Zeitalter

[Pö25b].

Transformational Skills für die digitale und nachhaltige Transformation 205

4 Regulationsfähigkeit und Persönlichkeitsentwicklung als

Schlüsselthemen

Die zentrale These dieses Beitrags lautet daher: Nachhaltige digitale Transformation

beginnt beim Menschen und ihren Kompetenzen – bei Menschen, die in der Lage sind,

sich selbst zu reflektieren, mit Unsicherheit umzugehen und gemeinsam mit anderen

zukunftsfähige Lösungen zu entwickeln [Ni20]. Daraus folgt eine Umkehr in der

Perspektive: Persönlichkeitsentwicklung ist kein individuelles Privatinteresse, es ist

vielmehr integraler Bestandteil organisationaler Entwicklung. Transformatives

Projektmanagement ist dabei die Weiterentwicklung des agilen Projektmanagement-

Frameworks, das zu kurz greift, um fundamentale Veränderungen nachhaltig zu

durchzuführen und zu verankern. Im transformativen Projektmanagement wird das agile

Framework um Reflexionsfähigkeit, emotionale Reife und Regulationsfähigkeit erweitert.

Als These lässt sich formulieren, dass Projekte der digitalen Transformation dann

besonders gut gelingen, wenn sie in einem emotional reifen und selbstreflektierten Umfeld

umgesetzt werden.

Dieses Denken wird gestützt durch das Konzept einer dreischichtigen Resilienz [Hu15],

das zwischen den Ebenen Individuum, Team und Organisation unterscheidet. Während

individuelle Resilienz emotionale Stabilität, Selbstfürsorge und persönliche

Stressbewältigung meint, geht es auf Teamebene um gegenseitiges Vertrauen, klare

Kommunikation und ein Bewusstsein für psychologische Sicherheit. Auf organisationaler

Ebene bedeutet Resilienz vor allem: Lernfähigkeit, wertebasierte Führung, strukturelle

Flexibilität – und Räume für Entwicklung [Bö24].

Zukunftsweisende Impulse, wie sie etwa Lena Lührmann in ihrer Keynote „ReThinking

Human Potential“ [Lü24] formuliert, betonen, dass es zur Entfaltung menschlichen

Potenzials unkonventionelles Denken, authentische Begegnung und intrinsische

Motivation braucht. Wer sich in Organisationen gesehen und ernst genommen fühlt, wird

bereit sein, Verantwortung zu übernehmen, Innovation zu wagen und nachhaltige

Veränderungen aktiv mitzugestalten.

Dies erfordert Führung, die nicht nur KPI-orientiert agiert, sondern Räume für

Entwicklung schafft – und den Mut, auch die „weichen Faktoren“ als Schlüssel zum Erfolg

zu erkennen [Ni20].

5 Zusammenfassung

Die hier vorgestellten Konzepte und Impulse eint eine gemeinsame Stoßrichtung: Digitale

und nachhaltige Transformation erfordert Tiefe. Sie gelingt nicht über Tools und

Methoden allein, denn sie benötigt ein neues Verständnis von Kompetenz, Kultur und

Menschsein in Organisationen. Wer sich auf Ansätze wie die IDGs oder

Schlüsselkompetenzen nach BNE einlässt, begibt sich auf eine Reise zu den Grundlagen

von Veränderung: innere Haltung, Selbstkompetenz und sinnorientiertes Handeln.

206 Kendra Pöhlmann und Julia Hodapp

Statt den Raum des Persönlichen vom Berufsleben abzukoppeln, ist es Zeit, die Potenziale

innerer Entwicklung gezielt in Organisationen zu integrieren. Persönlichkeitsentwicklung

ist keine individuelle Privatangelegenheit, sondern ein aktiver Beitrag zur kollektiven

Resilienz und Innovationsfähigkeit. Digitale Transformation gelingt nur dann nachhaltig,

wenn sie auch menschlich getragen ist.

Der Beitrag versteht sich als Einladung: zur Reflexion über das eigene

Führungsverständnis, zur Auseinandersetzung mit der Rolle von Emotionen in

Veränderungsprozessen – und zur Entwicklung einer werteorientierten, achtsamen und

zukunftsfähigen Organisationskultur.

Literaturverzeichnis

[An23] Ankrah, Doreen; Bristow, Jamie; Hires, Daniel; Henriksson, Jan; Inner Development

Goals: from inner growth to outer change, 2023, S. 82–87.

[Ba04] Baumeister, Roy F. (Hrsg.); Handbook of self-regulation: Research, theory, and

applications, New York, NY. Guilford Press, 2004.

[Bö24] Böhme, Rebecca; Resilienz: Die psychische Widerstandskraft, 2. Auflage, München.

C.H. Beck, 2024.

[BLB24] Bremer, Ann-Kathrin; Lindau, Anne-Kathrin; Brok, Ulrike; Entwicklung von

Nachhaltigkeitskompetenzen bei Studierenden im Service Learning – ein

Erhebungsinstrument zur Selbsteinschätzung, in: ZEP – Zeitschrift für internationale

Bildungsforschung und Entwicklungspädagogik, 2024, 2025, S. 10–14.

[Br21] Brundiers, Katja; Barth, Matthias; Cebrián, Gisela; Cohen, Matthew; Diaz, Liliana;

Doucette-Remington, Sonya; Dripps, Weston; Habron, Geoffrey; Harré, Niki; Jarchow,

Meghann; Losch, Kealalokahi; Michel, Jessica; Mochizuki, Yoko; Rieckmann, Marco;

Parnell, Roderic; Walker, Peter; Zint, Michaela; Key competencies in sustainability in

higher education—toward an agreed-upon reference framework, in: Sustainability

Science, 16, 2021, S. 13–29.

[DT20] Dahm, Markus H.; Thode, Stefan (Hrsg.); Digitale Transformation in der

Unternehmenspraxis: Mindset - Leadership - Akteure - Technologien, Wiesbaden,

Heidelberg. Springer Gabler, 2020.

[DH25] Detscher, Stefan; Hepp, Michael (Hrsg.); Praxishandbuch Digitales Management.

Springer Gabler, 2025.

[Eh20] Ehlers, Ulf-Daniel; Future Skills, Wiesbaden. Springer Fachmedien Wiesbaden, 2020.

[ER07] Erpenbeck, John; Rosenstiel, Lutz von; Handbuch Kompetenzmessung Erkennen,

Verstehen und Bewerten von Kompetenzen in der betrieblichen, pädagogischen und

psychologischen Praxis, 2. Auflage, Stuttgart. Schäffer-Poeschel, 2007.

[Ge23] Geyer, Christian; Die post-agile Organisation, https://www.christian-geyer.com/12/die-

post-agile-organisation.html?utm_source=chatgpt.com.

Abgerufen am 07.08.2025.

[Hu15] Huber-Metz, Birgit; Kernkompetenz Resilienz, in: Sozialwirtschaft, 25, 2015, S. 30–31.

Transformational Skills für die digitale und nachhaltige Transformation 207

[Lü24] Lührmann, Lena; Rethinking Human Potential: Ungenutzte Zukunftschancen in

Unternehmen, Regensburg, 10.07.204. Innovationskongress Regensburg, 10.07.204.

[Ma24] Mattenberger, Matthias; Was bedeutet BANI, Hochschule für Wirtschaft Zürich, 2024,

https://fh-hwz.ch/news/was-bedeutet-bani. Abgerufen am 28.06.2025.

[Ni20] Nink, Marco; Auf den Menschen kommt es an!: Die Bedeutung weicher Faktoren in der

digitalen Transformation, in: Markus H. Dahm, Stefan Thode (Hrsg.), Digitale

Transformation in der Unternehmenspraxis: Mindset - Leadership - Akteure -

Technologien, Wiesbaden, Heidelberg, Springer Gabler, 2020, S. 27–44.

[Pö25] Pöhlmann, Kendra; Achtsamkeit und Agilität, Regensburg, OTH Regensburg,

28.05.2025. Achtsamkeit im Arbeitsalltag, 28. Mai 2025.

[PH25] Pöhlmann, Kendra; Hodapp, Julia; Impulse zur integrierten Umsetzung von

Digitalisierung und Nachhaltigkeit: Von der Twin Challenge zur Twin Transformation,

in: Stefan Detscher, Michael Hepp (Hrsg.), Praxishandbuch Digitales Management,

Springer Gabler, 2025.

[SMA19] Sabini, Luca; Muzio, Daniel; Alderman, Neil; 25 years of ‘sustainable projects’. What

we know and what the literature says, in: International Journal of Project Management,

37, 2019, S. 820–838.

[SS14] Silvius, A. Gilbert J.; Schipper, Ron P.J.; Sustainability in project management: A

literature review and impact analysis, in: Social Business, 4, 2014, S. 63–96.

[SS20] Schwaber, Ken; Sutherland, Jeff; The Scrum Guide: The Definitive Guide to Scrum:

The Rules of the Game, 2020, https://scrumguides.org/docs/scrumguide/v2020/2020-

Scrum-Guide-US.pdf#zoom=100. Abgerufen am 28.06.2025.

[Un17]] UNESCO; Education for Sustainable Development Goals: learning objectives.

UNESCO, 2017.

[Va19] Vare, Paul; Arro, Grete; Hamer, Andre de; Del Gobbo, Giovanna; Vries, Gerben de;

Farioli, Francesca; Kadji-Beltran, Chrysanthi; Kangur, Mihkel; Mayer, Michela;

Millican, Rick; Nijdam, Carlien; Réti, Monika; Zachariou, Aravella; Devising a

Competence-Based Training Program for Educators of Sustainable Development:

Lessons Learned, in: Sustainability, 11, 2019, S. 1890.

208

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 209

Die Table of PM Elements als Wegweiser im post-agilen

Projektalltag

Bernhard Schloß1

Abstract: Inmitten von Transformation, Unsicherheit und Methodeninflation suchen Projektverant-

wortliche nach Orientierung. Die Table of PM Elements bietet einen methodenübergreifenden Ord-

nungsrahmen für kontextsensibles Projektmanagement - ein Methodensystem für Projekte. Der Bei-

trag beschreibt die Entstehung, die Methodenselektion und Systematik der Table und zeigt anhand

ausgewählter Praxisbeispiele ihren Nutzen im post-agilen Projektalltag.

Keywords: Methodik, Orientierung

1 Die Table und ihre Geschichte

Die Grundidee des Projektmanagements ist, dass wir nicht "irgendwie" an das Projektziel

gelangen, sondern möglichst systematisch und professionell. Dafür braucht es Methoden

und Werkzeuge.

Methoden und Werkzeuge sind aber bei Weitem nicht alles. Es gibt drei Säulen erfolgrei-

cher Projektarbeit und Methoden sind nur einer dieser drei. Projekte werden von und für

Menschen gemacht und sie finden immer auch in einem bestimmten Kontext, in einem

bestimmten Umfeld statt. Für erfolgreiche Projektarbeit müssen diese drei Säulen aufei-

nander abgestimmt sein und ineinandergreifen.

Die Methodenvielfalt im Projektmanagement ist riesig. Die Table of PM Elements will

hier Orientierung geben. Ursprünglich entstand die Table durch die systematische Aus-

wertung von Trainingsinhalten, einschlägiger Literatur und gängigen PM-Glossaren. Er-

gebnis war eine Liste von 304 Methoden und Werkzeugen, die für Projekte verschiedener

Branchen relevant sind und sich unabhängig von Standards anwenden lassen. Nischenme-

thoden ohne breitere Praxisrelevanz wurden nicht aufgenommen.

Um die Vielzahl an Methoden handhabbar zu machen, entwickelten wir iterativ Attribute,

die eine Differenzierung ermöglichen: Anwendungsbereich, Nutzerkreis, Aufwand, Wirk-

samkeit und zeitlicher Einsatz im Projektverlauf. Anschließend wurden ähnliche Metho-

den zusammengefasst, um eine kompaktere Darstellung zu erreichen.

1 mail@bernhardschloss.de

210 Bernhard Schloß

Abb. 1: Table of PM Elements2

2 Eine digitale Version der Table inklusive aller Details auf den Kacheln steht zur Verfügung unter:

https://www.table-of-elements.io/assets/downloads/Table_of_PM_Elements.pdf

Die Table of PM Elements als Wegweiser im post-agilen Projektalltag 211

Die Inspiration für die visuelle Umsetzung stammt vom Periodensystem der Chemie: Die

Table ordnet Methoden zweidimensional, gruppiert sie nach Anwendungsfeldern (Pla-

nung & Steuerung, Team & Umwelt, Anforderungen, Qualität & Risiko, Konzepte,

Frameworks) und nutzt Farbcodes für unterschiedliche Methodentypen.

Farblich codiert finden sich typische Projektmanagement-Methoden, allgemeine Manage-

ment-Methoden, Kommunikationswerkzeuge, agile Tools und Kreativitätswerkzeuge.

Die einzelnen "Kacheln" sind wie folgt aufgebaut: Ein Kürzel (abgeleitet aus dem Engli-

schen und der Methodenname. Rechts oben eine subjektive Sternebewertung der Autoren,

der Typ (ob eine Methode eher dem Verstehen dient, der Empathie oder der Umsetzung),

die Nutzer (wird ein Werkzeug von einem Projektmitarbeiter alleine eingesetzt, im Team

oder ist sowohl als auch möglich). Eine Bewertung von Aufwand, Schwierigkeit und

Wirksamkeit und links unten ein Indikator für den Einsatzzeitpunkt (eher zu Beginn eines

Projekts, am Ende oder zeitlos).

Abb. 2 – Die Kachel für den Projektstrukturplan (WBS)

Die Übersicht der Table gibt es als Poster. Die kompakten Beschreibungen und Anleitun-

gen, gibt es in der dazugehörigen App "PM Elements" (iOS) bzw. im Buch "Das Metho-

densysteme für Projekte" [SB25]. Derzeit entsteht auch eine umfangreiche Videobiblio-

thek zur Table auf LinkedIn Learning („Projektmanagement-Methoden: Jede Woche

neu“).

Jedes Element ist nach einem einheitlichen Schema dokumentiert: Name, Kürzel, Defini-

tion, verwandte Methoden, Schritt-für-Schritt-Anleitung, Bewertung und Einsatzempfeh-

lungen. Diese Standardisierung unterstützt die reflektierte Auswahl und den bewussten

Einsatz von Methoden. Projektteams können über Attribute filtern, Optionen vergleichen

und Methoden kontextgerecht kombinieren – unabhängig davon, ob sie klassisch, agil oder

hybrid arbeiten.

212 Bernhard Schloß

Etwas abweichend von diesem Schema sind die Konzepte und Frameworks am unteren

Rand der Table. Hier sind die Kacheln mit einem spezifischen Symbol versehen und in

der Beschreibung folgt die Bewertung nicht dem gerade beschriebenen Muster sondern

listet Vor- und Nachteile auf.

2 Nutzen der Table of PM Elements

Die Table of PM Elements ist zunächst nur ein grafisches Schema, das die einzelnen

Werkzeuge in einer geordneten Struktur abbildet. Hinter der Table liegt aber ein Metho-

den-Katalog mit strukturierten Beschreibungen aller Methoden und Werkzeuge aus der

Übersicht.

Die Table ist ein pragmatischer Ansatz, um Orientierung zu geben und den Methodenein-

satz zu reflektieren. Indizes, Filter und Volltextsuche erlauben kontextspezifisch eine ge-

zielte Suche.

Die Table ist frei von Dogmatik. Es wird keine Projektmanagement-Methodik/-schule

vorgegeben. Sie hilft, passende Methoden kontextgerecht auszuwählen, situationsgerecht

einzusetzen und bewusst zu kombinieren. Querverweise auf verwandte Methoden zeigen

Alternativen, Ergänzungen oder Vertiefungsmöglichkeiten.

Die Table macht Projektteams handlungsfähig – ob klassisch, agil oder irgendwo dazwi-

schen. Gleichzeitig setzt sie aber eine Systematik der Beliebigkeit in der Methodenwahl

entgegen.

Durch die Vielschichtigkeit der enthaltenen Werkzeuge schafft sie Flexibilität im Einsatz

- von resilienter Reaktion bis hin zu zielorientierter Struktur.

3 Einsatzmöglichkeiten in verschiedenen Kontexten

Die Table of Elements lässt sich im Projektalltag (als Nachschlagewerk oder zur Anregung

bei Blockaden, Planungen, Retrospektiven), ebenso einsetzen, wie in Lehre oder Weiter-

bildung, als "Werkzeugkasten" für Lernende oder als Strukturgeber in Seminaren. Auf or-

ganisatorischer Ebene bietet die Table ein gemeinsames Verständnis bei der PM-Einfüh-

rung. Sie ist darüber hinaus customizbar für firmeninterne Prozesse und Sprache.

Nehmen wir einen exemplarischen Anwendungsfall: unklare Rollen und Aufgaben im

Projekt. Welche Bausteine liefert uns hier die Table of Elements?

Da sind die RACI-Matrix und der Role-Model Canvas als Werkzeuge zur Rollenklärung.

Für die Aufgabenklärung finden sich die 3W (Wer macht was bis wann), das Taskboard

oder die Offene Punkte Liste. Bei unklaren Aufgaben im Sinne von Anforderungen sind

wir im Requirements Engineering.

Ein weiteres Anwendungsbeispiel sind mangelhafte Priorisierungen von Aufgaben oder

Problemen. Die Table of Elements hält eine ganze Reihe von Priorisierungswerkzeugen

Die Table of PM Elements als Wegweiser im post-agilen Projektalltag 213

parat: Angefangen von Matrizen zur Priorisierung (Eisenhower-Matrix, MoSCoW-Me-

thode und Wow-how-now-ciao-Matrix), Tools die das Pareto-Prinzip (80-20-Regel) um-

setzen wie die ABC-Analyse oder das Pareto-Chart, das Kano-Modell zur Bewertung von

Anforderungen, bis hin zur Priorisierung in Listenform, z.B. in einer offenen Punkte-Liste.

Nahezu jede Fragestellung im Projekt lässt sich mit der Table bearbeiten, ohne dass ein-

fache Antworten vorgegeben werden. Der systematische Einsatz von Werkzeugen wird

gefördert, das Konzept enthält Anregungen auch aus anderen Bereichen und den verschie-

denen Projektmanagement-Ansätzen von traditionell bis agil.

Und wenn es dann darum geht die einzelnen Werkzeuge konkret einzusetzen, hilft wieder

das standardisierte Beschreibungsformat, das schnell und unkompliziert die Werkzeuge

nutzbar macht und ein gemeinsames Methodenverständnis schafft.

4 Anknüpfung an Post-Agilität, Resilienz und Transformation

Welche Anknüpfungspunkte liefert die Table of PM Elements für Post-Agilität, Resilienz

und Transformation?

Die Table bewegt sich jenseits binärer Denkmodelle (klassisch vs. agil). Sie liefert Orien-

tierung statt Methodenglaube. Sie unterstützt einen reflektierten Methodeneinsatz. Auch

im Zeitalter der Post-Agilität sind agile Methode weiterhin sinnvoll einsatzbar, ebenso wie

traditionelle Werkezeuge oder Werkzeuge aus angrenzenden Disziplinen (Management,

Kommunikation, Kreativität).

Im Sinne von Resilienz sorgt sie für Reaktionsfähigkeit durch Struktur und Reflexion und

unterstützt mit ihren Beschreibungen den Methodeneinsatz.

Für die Transformation liefert sie einen Methoden-Baukasten mit Denkwerkzeugen für

Wandelprozesse und neue Formen der Zusammenarbeit.

Literaturverzeichnis

[SB25] Schloß, B.; Botta, C.: Das Methodensystem für Projekte: Finden Sie die passende Me-

thode für Ihr Projektmanagement, München, 2025.

214

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 215

Challenges of Integrating Agile Development and Analyti-

cal Quality Assurance

Sven Theobald1 und Christopher Rottmann2

Abstract: Agile development approaches are increasingly used to develop software in many com-

panies that relied on traditional development approaches in the past. Agile is also increasingly uti-

lized to develop safety critical products that need rigorous quality assurance, e.g., in the automotive

domain. The question is if agile development environments and analytical quality assurance are

sufficiently integrated. Initially, eight hypotheses about typical challenges regarding the integration

of agile and analytical quality assurance were proposed by the authors based on their experiences.

These hypotheses are then evaluated with the help of seven expert interviews and a review of rele-

vant literature. Results suggest that analytical quality assurance is indeed insufficiently integrated

with agile development.

Keywords: Agile Software Development, Analytical Quality Assurance, Challenges.

1 Introduction

The size and complexity of software and systems is constantly increasing. Agile ap-

proaches that help to deal with complexity are already dominant in software development

[Fl22][Di21]. Besides the information system domain, agile methods are also increasingly

used when developing embedded software products, safety critical products or in general

products with rigorous quality demands [DT18].

Another aspect of development therefore also gained importance - quality assurance. This

discipline was historically deeply integrated in stage-gate-models, conventional develop-

ment processes, and strict schedules. “Processes, tools, documentation, and following a

plan” were “the cornerstones of rigorous quality assurance and testing practices” [It05].

In sharp contrast to these fundamental requirements, the agile approach emphasizes “in-

dividuals and interactions, customer collaboration, and responding to change”

[It05][Be01]. It clearly favorizes constructive quality assurance methods, while analytical

practices with destructive attitude, such as traditional testing, are almost completely aban-

doned [It05]. In fact, the twelve agile principles contain the word develop five times and

software three times, while quality, test, or validate are not mentioned at all [Be01].

These discrepancies give room to the initial assumption that there might be interface prob-

lems [TD18] due to the different nature of both disciplines. Eventually, we observed that

these problems can decrease the efficiency and motivation in the quality assurance teams

and can cause friction at the interfaces to other domains, such as development or require-

ment engineering. Additionally, due to the decreased efficiency, the pressure on the teams

and associated employees can rise which could lead to a spiral of demotivation.

1 Fraunhofer IESE, Data Science, Fraunhofer-Platz 1, 67663 Kaiserslautern, sven.theobald@iese.fraunhofer.de

2 Gira Giersiepen GmbH & Co. KG, Dahlienstraße 12, 42477 Radevormwald, chriro@gmx.de

216 Sven Theobold und Christopher Rottmann

Thus, based on our experiences of working in and with companies, we derived the follow-

ing hypothesis: Analytical quality assurance is not sufficiently considered and integrated

by the agile approach. As a result, it faces an increased number of challenges when being

executed in an agile environment. This eventually leads to shortcomings and decreased

efficiency in analytical quality assurance. This hypothesis was evaluated in the context of

a master’s thesis [Ro22], by interviewing seven experts and reviewing relevant literature.

The remainder of this paper is as follows: Section 2 provides the background on quality

assurance. In Section 3, we show the research method including the derived sub-hypothe-

ses. The results are shown and discussed in Section 4. Finally, Section 5 concludes the

paper and provides an outlook for future work.

2 Background

Quality assurance (QA) is a discipline whose main concern is to ensure that a product can

deliver the desired maturity on relevant quality characteristics. QA activities can be di-

vided into two major domains: constructive quality assurance (CQA) and analytical qual-

ity assurance (AQA) [Li20]. CQA aims at achieving the desired quality in the intermediate

artifacts. Quality is “built-in” rather than tested at the end. Most agile practices that con-

tribute towards an increased product quality [TD17] can be assigned to CQA. In contrast,

AQA is concerned with the original task of QA: validation of the quality of products to be

released. The difference with respect to traditional QA is that not only the final product,

but also intermediate work results are validated.

While CQA responsibilities are often at least partially taken over by agile teams, AQA is

traditionally executed by specialized validation teams, external to the agile development

team. However, some of the AQA methods are typically also performed by the developers

themselves. This is particularly true for methods which have a strong correlation with the

actual software development, such as code complexity checks or code reviews.

Methods which are applied to higher product levels like system tests or user acceptance

tests are often difficult to perform on team level. Especially when developing complex

products that are composed of several sub-components, most of the higher level AQA

activities are still carried out by specialized teams external to the development. Although

there are frameworks to scale agility throughout an organization that consider the collab-

oration between quality assurance and agile teams [TS20], many agile implementations

have suboptimal interfaces between agile development teams and a traditional quality as-

surance world [TD18].

3 Research Method

This section provides an overview of the derived sub-hypotheses, the process for the con-

duction of the interviews and the literature search, as well as data analysis process.

Challenges of Integrating Agile Development and Analytical Quality Assurance 217

3.1 Derived Sub-Hypotheses

When investigating the interface between Analytical Quality Assurance (AQA) and agile

development, we consider all possible challenges, e.g. related to processes, tools or people.

Eight sub-hypotheses were derived from the initial hypothesis (see Table 1) based on past

experiences of the authors. The goal was to specify each hypothesis with sufficient detail

to enable an evaluation based on the findings of the literature search and expert interviews.

Table 1. Initial hypotheses [Ro22]

Hypothesis

Description

1 Planning

Giving a reliable forecast on overall development effort and cost is very dif-

ficult in (real) agile projects. Forecasting overall AQA effort and cost is even

worse and almost impossible but often still demanded.

2 Test Effort

If a hypothetical project is developed both ways, conventional and agile, the

effort and cost spent on AQA in the agile project is significantly higher.

3 Regression

Agile development potentially promotes regression which makes counter-

measures necessary. Appropriate measures could be installed in CQA but

mostly they are performed as AQA which is very ineffective and expensive.

4 Test Auto-

mation

Test automation is widely accepted as the only way for AQA to keep up with

the fast-paced agile development, but it also introduces new challenges itself.

5 Changes

The agile way of dealing with changes causes a serious decrease in AQA ef-

ficiency due to an excessive amount of rework and duplication.

6 Test Levels

The effects of agile development on AQA are not evenly distributed or uni-

form. Some positive effects apply to activities on levels of lower abstraction

(such as Software Unit Verification), whereas levels with higher abstraction

(such as System Qualification Test) are to a large extent challenging.

7 Tooling

If AQA is not operated in the same tool environment together with related

domains, a lack of synchronization will be the result. The subsequent impli-

cations are especially problematic in agile projects and must be avoided.

8 Safety

The AQA related demands posed by domain specific safety standards/regula-

tions are incompatible or at least difficult to achieve with agile projects.

Expert interviews and a literature search were conducted for elicitation of raw data to con-

firm or reject the main hypothesis based on the defined sub-hypotheses. During the pro-

cess, five additional hypotheses were raised that are described in Section 4.

3.2 Expert Interviews

The interview was divided into two parts (see Table 2). The first part was an open inter-

view aimed at identifying new hypotheses. The second part consisted of a fixed set of

questions to confirm the existing hypotheses.

218 Sven Theobold und Christopher Rottmann

Table 2. Interview Guideline [Ro22]

The target population of the interview study was defined as AQA stakeholders that have

experience at the interface of agile development and traditional AQA. Candidates were

required to comply with the minimum requirements: being a provider to or consumer of

AQA for at least 2 years or executing or managing AQA actively for more than one year;

participating in at least one pseudo-agile project or profound knowledge about agile de-

velopment in theory; participating in at least one traditional project or profound knowledge

about traditional development in theory; having experience in at least one domain.

The convenience sample consisted of seven interview participants that all complied with

the defined requirements. Four candidates have previously worked in at least one agile

project, two candidates reported experience with pseudo agile projects, while one candi-

date knew agile projects only in theory. Traditional projects were done by six candidates,

whereas one candidate only had theoretical experience with traditional development. Five

candidates had more than 3 years of experience with AQA, while 2 candidates had less

than 2 years of experience. In addition, four interviewees had more than five years of work

experience in total. Most candidates were working in the automotive domain (6 out of 7).

The second author executed the interviews from June to August 2022 using the interview

Part One: Open Interview (Candidate Driven)

Objective

Mining of new, undiscovered challenges, issues, or hypotheses from the

candidate without having influenced the candidate by prior interviewer

questions.

Duration

Approximately thirty minutes

Methodology

After the organizational introduction, the interviewer passes control to

the candidate. The candidate is requested to freely report about chal-

lenges and problems related to the combination of AQA and agile de-

velopment that he or she faced in his or her career. If aspects are identi-

fied, the interviewer asks the candidate if the problem/challenge was

solved and if so, which way.

Formalism

Solutions and aspects identified during the open interview are noted

down by the interviewer briefly in the Statement Documentation Sheet

(SDS, see Fig. 1).

Part Two: Hypothesis based Interview (Interviewer Driven)

Objective

Receive confirmation or dissent on the derived hypotheses from Chap-

ter 3, presented by the interviewer.

Duration

Approximately forty-five minutes

Methodology

Lead questions are defined based on the given hypotheses. The ques-

tions are presented by the interviewer and discussed with the candidate.

Formalism

Collected discussion results and potential solutions are also noted down

by the interviewer briefly in the SDS.

Challenges of Integrating Agile Development and Analytical Quality Assurance 219

guideline. The interviews took one hour and twenty-seven minutes on average. Five of the

seven interviews were executed offline as personal meetings. The remaining two inter-

views were held as online meetings using a videoconferencing tool. Generally, all inter-

views were voice recorded complemented with additional handwritten notes including

timestamps, to facilitate the later analysis. A documentation template, hereinafter referred

to as Statement Documentation Sheet (SDS), was used to keep all notes uniform and com-

parable (c.f. Figure 1).

3.3 Literature Search

Complementary to the expert interviews, the second author also executed a literature

search to collect data from scientific literature. The search was conducted in June and July

2022. The search for appropriate literature (English or German, not older than 20 years)

started with a keyword search on Google Scholar, using the following search strings:

• [challenges; difficult; problematic] agile testing

• [analytical] quality assurance in agile projects

• [validation; V&V] in agile

• agile vs traditional [testing; validation; analytical quality assurance]

As some of the identified literature was quite generic regarding agile and AQA, a consec-

utive search was performed on the literature that was referenced in relevant sections of the

generic literature. Eventually, the combination of both techniques revealed a set of sources

[It05][Hu04][Pu06][Bl09][Sn13] that were screened to identify new hypotheses (chal-

lenges), solutions, as well as approval or dissent on the existing hypotheses.

3.4 Analysis Process

The audio captions and hand-written notes from the interviews, as well as the identified

literature were examined to extract key statements regarding Agile and AQA. Similar

statements were aggregated into one challenge and documented in the Statement Docu-

mentation Sheet (SDS) (see Figure 1).

Each challenge was further categorized regarding the affected interface (AQA towards the

customer, towards management, towards project leader, towards Product Owner, towards

requirements engineer, towards system engineering, towards software development or to-

wards internal testing). Also, it was classified whether the challenge relates to an artifact

or activity, and whether it relates to the input or output of AQA. If available, solutions for

the challenges were documented.

Finally, each challenge was assigned to one or more hypotheses. A new hypothesis was

added in case the statement did not match an existing hypothesis. Similar challenges that

relate to the same hypothesis were aggregated in one template.

Each hypothesis was then evaluated by the second author based on the related challenges,

rating the agreement of the associated statements of each related challenge with the hy-

pothesis using the following 5-point scale: Direct disagreement -2, indirect disagreement

-1, neutral opinion 0, indirect agreement 1, direct agreement 2. The term indirect applies,

220 Sven Theobold und Christopher Rottmann

whenever a statement does not directly match the description, but it still describes a relat-

able matter that is either similar to or originates from the provided root cause. Finally, the

mean agreement level per source (literature or interview) and hypothesis was calculated

and added to the SDS.

Challenge: Estimation/Planning is difficult in agile projects (Arithmetic Mean: 5/3)

Statements:

 “Audits asked us for some kind of planning but the estimation of testing

effort for unknown requirements is just not possible.” (+2)

 “Agile and fix deadlines simply do not match.” (+2)

 Distributed development makes it unclear in agile projects

who is responsible for what, when. (+1)

Affected Interface: Customer | MGMT | PL | PO | RQE | SE | DEV | TEST

Classification: Artifact or Activity | Input or Output

Safety

Solution or Solution Proposal:

 Planning in larger scales and more complex projects is proposed

in SAFe as PI (Program Increments).

Fig. 1. Example of SDS after Evaluation

The final agreement level (FAL) for each hypothesis is calculated based on all available

mean agreement levels of different sources with the formula:

()=

�(,)



=

ℎ: (,)=      ℎℎ 

: =      ℎℎ 

4 Results and Discussion

Following the given procedure, a total number of seventy-eight statements was docu-

mented and analyzed. The overall distribution between statements from interviews and

those sourced from literature was computed, revealing that interviews constitute the pre-

dominant source of data, slightly surpassing 70% of the total fraction.

The collected statements revealed five further problem hypotheses in addition to the eight

derived sub-hypotheses, namely:

Challenges of Integrating Agile Development and Analytical Quality Assurance 221

• Variants: Variants of products are not considered in test case creation, which leads to

problems in AQA.

• Trimmed Agile: There is a lack of preparation/transformation ahead of the actual agile

project, trimming agile due to the restrictions caused by upfront planning.

• Testing Timeout: Agile is challenging for testing due to rapid release cycles that put

fixed deadlines for testing activities and do not allow extending testing period in case

more defects are found than estimated.

• Missing independency: Independency is a fundamental principle of testing; hence a

programming organization should not test their own programs.

• Testing Expertise: Software testing requires specific skills and experiences; thus, a pro-

fessional tester is required to perform effectively and efficiently.

A heatmap summarizes the analysis results (see Figure 2). This heatmap shows for each

sub-hypothesis (column) the mean agreement level extracted from each interview (IVx)

and literature (LIx) source (rows). In addition, the final agreement level (FAL) for the

respective sub-hypothesis is shown in the bottom row. The values for the mean agreement

level shown in each cell (and for the FAL values in the bottom row) range from -2 to 2. In

more detail, values between -2 and -1.5 show direct disagreement, values between -1.5

and -0.5 show indirect disagreement, -0.5 to 0.5 represents the neutral opinion, 0.5 to 1.5

the indirect agreement, and 1.5 to 2 the direct agreement. “N/A” shows that the source

does not mention the challenge described in the sub-hypothesis.

Fig. 2. Heatmap with summarized analysis results [Ro22]

Out of the resulting thirteen hypotheses, twelve received at least indirect agreement and

six even direct agreement on average. Based on the qualitative research performed on the

topic, the initially stated hypothesis was corroborated. AQA is indeed insufficiently con-

sidered by the agile approach and transformation, still resulting in numerous problems and

challenges. Practitioners that already experienced inefficiencies in the collaboration of ag-

ile development teams and traditional AQA teams might want to focus on solving the

challenges described in the following five sub-hypotheses that seem to find support in

most sources:

222 Sven Theobold und Christopher Rottmann

• Planning: Forecasting AQA effort is very difficult in agile but still demanded.

• Test Effort: Better product quality in agile is paid by higher AQA effort.

• Regression: Agile promotes regression, and regression related to AQA is expensive.

• Changes: Changes in agile projects cause redundant work and duplication in AQA.

• Test Levels: Higher level AQA exceedingly suffers from negative effects by agile.

Many of the identified AQA problems were traced back to common root causes. Espe-

cially the agile flexibility combined with high release frequencies and low priority on doc-

umentation negatively impacts the efficiency of many AQA activities, such as planning,

testcase creation, and test automation due to more and redundant effort.

The results obtained from this limited number of interview participants should not be over-

interpreted to depict the challenges of all agile and AQA stakeholders. With a larger sam-

ple size, more of the supposedly diverse situations of agile and AQA teams could be cov-

ered, so that additional hypotheses would most likely be identified until saturation is

reached. Also, the agreement on the existing hypotheses would better represent all practi-

tioners. In addition, since the results heavily rely on data from interviews where the par-

ticipants almost all came from the automotive domain, there is a limited generalizability

of the results to other domains. The rating of the identified statements might sometimes

be subjective, especially when rating the indirect agreement. Newly identified challenges

that were mentioned in later interviews led to the definition of new hypotheses, which then

were not explicitly asked in the previous interviews. This explains why there are fewer

ratings for the new hypotheses.

5 Conclusion and Future Work

With the rise of agile development approaches even in projects where rigorous quality

assurance is required, traditional testing approaches must coexist with fast-paced agile

development. In the context of a master’s thesis, typical challenges at the intersection of

both approaches were investigated. This work proposed eight initial hypotheses about dif-

ferent challenges regarding the integration of agile development environments and analyt-

ical quality assurance. These hypotheses were later evaluated with the help of seven expert

interviews as well as a review of relevant literature.

Five hypotheses can be highlighted as they received agreement over most sources. In ad-

dition, five new challenges were identified. Thus, results suggest that analytical quality

assurance is indeed insufficiently integrated with agile development.

As for future work, consecutive research could try to quantify the identified challenges,

for example with the help of an online survey using the findings of this work. The under-

lying thesis already collected potential solutions for the identified challenges which could

also be reported. Overall, guidelines for the collaboration between agile development and

analytical quality assurance could support practitioners in their daily work.

Challenges of Integrating Agile Development and Analytical Quality Assurance 223

References

[Be01] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J.

Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. Martin, S. Mellor,

K. Schwaber, J. Sutherland and D. Thomas, "Principles behind the Agile Manifesto,"

2001. [Online]. Available: https://agilemanifesto.org/principles.html.

[Bl09] S. Black, P. P. Boca, J. P. Bowen, J. Gorman and M. Hinchey, "Formal Versus Agile:

Survival of the Fittest," Computer Volume 42, 2009.

[Di21] Digital.ai: The 15th State of Agile Survey (2021).

[DT18] Diebold P, Theobald S. How is agile development currently being used in regulated em-

bedded domains?. J Softw Evol Proc. 2018;1935. https://doi.org/10.1002/smr.1935.

[Fl22] J. Flynn, "16 Agile Statistics [2022]: What You Need To Know About Agile Project

Management," 2022. [Online]. Available: https://www.zippia.com/advice/agile-statis-

tics/.

[It05] J. Itkonen, K. Rautiainen and C. Lassenius, "Towards Understanding Quality Assurance

in Agile Software Development," in International Conference on Agility 2005, Helsinki,

2005.

[Li20] Liggesmeyer, P. (2020). Textbook V-M. 1.1: Software Engineering for Embedded Sys-

tems: Software Quality Assurance. TU Kaiserslautern.

[Pu06] M. Puleio, "How not to do agile testing," in AGILE 2006 (AGILE'06), Minneapolis,

2006.

[Ro22] Rottmann, J.C.: Improving the Integration of Analytical Quality Assurance in Agile

ProducteDevelopments,e2022,

Available: https://nbn-resolving.org/urn:nbn:de:hbz:386-kluedo-70223.

[Sn13] H. M. Sneed, "Agiles Testmanagement," Rundbrief des Fachausschusses Management

der Anwendungsentwicklung und -wartung (WI-MAW), 2, 2013.

[TD17] Theobald, S., Diebold, P. (2017). Beneficial and Harmful Agile Practices for Product

Quality. In: Felderer, M., Méndez Fernández, D., Turhan, B., Kalinowski, M., Sarro, F.,

Winkler, D. (eds) Product-Focused Software Process Improvement. Lecture Notes in

Computer Science(), vol 10611. Springer, Cham. https://doi.org/10.1007/978-3-319-

69926-4_48

[TD18] Theobald, S., Diebold, P.: Interface Problems of Agile in a Non-agile Environment. In:

Garbajosa, J., Wang, X., Aguiar, A. (eds.) Agile Processes in Software Engineering and

Extreme Programming. 19th International Conference, XP 2018, Porto, Portugal, May

21–25, 2018, Proceedings / Juan Garbajosa, Xiaofeng Wang, Ademar Aguiar, 314.

Springer, Cham (2018).

[TS20] Theobald, S., Schmitt, A. (2020). Dependencies of Agile Teams – An Analysis of the

Scaled Agile Framework. In: Paasivaara, M., Kruchten, P. (eds) Agile Processes in Soft-

ware Engineering and Extreme Programming – Workshops. Lecture Notes in Business

Information Processing, vol 396. Springer, Cham. https://doi.org/10.1007/978-3-030-

58858-8_22.

[Ve04] M. Hue, J. Verner, L. Zhu and M. A. Babar, "Software quality and agile methods," in

Proceedings of the 28th Annual International Computer Software and Applications Con-

ference 2004, Hong Kong, 2004.

224

Teil III

Praxisbeiträge

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 227

Agil, um jeden Preis?

Sercan Cevik1

Abstract: Strategische Vorhaben und Transformationen, z.B. zur Digitalisierung schei-

tern in der Mehrzahl der Fälle. Studien und regelmäßige Pressemeldungen belegen dies.

Der Beitrag bietet zu Beginn einen Überblick zu wesentlichen Ursachen. Ein professio-

nelles und flexibles Programmmanagement als möglicher Lösungsansatz wird in Folge

vorgestellt. Speziell werden dabei Unterschiede zu Projektmanagement aufgezeigt, das

den Anforderungen dieser Vorhaben regelmäßig nicht gerecht wird, nicht gerecht werden

kann. Im Kern geht dabei auf die zentrale Bedeutung des erwarteten Nutzens aus dem

strategischen Vorhaben und seine Steuerung von der Strategie hin zur operativen Umset-

zung. Zentral ist es ebenfalls zu Beginn des Vorhabens den Umfang und die Reichweite

richtig einzuschätzen. Dabei geht es nicht darum eine Reihe von Projekten zu koordinie-

ren. Vielmehr sind alle notwendigen Vorhaben und Aktivitäten im Unternehmen auf das

strategische Ziel auszurichten und zu steuern. Besonders gefordert ist dabei die Führungs-

ebene eines Unternehmens. Hierzu wird ein einfaches Vorgehensmodell anhand eines

Fallbeispiels genutzt. Persönliche Erfahrungen aus Praxisvorhaben in IT-Unternehmen

sind Bestandteil des Beitrags.

Der Beitrag unterstützt Sie dabei, strategische Vorhaben von vorneherein richtig einzu-

schätzen und zu organisieren.

Keywords: agil, agiles PM, hybrid, hybride, Frameworks, Vorgehensmodelle

1 cevik.pm, Riehlstr. 7, 90489 Nürnberg, cevik@cevik.pm

228

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 229

Agil gescheitert? Warum agile Transformationen ins Sto-

cken geraten – und wie Projekte trotzdem gelingen

Thorsten Nottebaum1

Abstract: Unternehmen nutzen agile Ansätze, um Projekte wirksamer zu gestalten, die

Zusammenarbeit in Teams zu verbessern und flexibler auf Veränderungen reagieren zu

können. In der praktischen Umsetzung zeigen sich jedoch häufig strukturelle, kulturelle

und kommunikative Herausforderungen. Agile Praktiken werden zwar eingeführt, aber

nicht konsequent mit klaren Verantwortlichkeiten, lernfähigen Prozessen und einer ein-

deutigen Zielorientierung verknüpft. Dieser Beitrag untersucht auf Basis verschiedener

Studien und Praxiserfahrungen, welche Faktoren den Erfolg agiler Transformationen prä-

gen und welche typischen Stolpersteine auftreten. Im Anschluss wird mit AlignPRO® ein

post-agiles Betriebsmodell vorgestellt, das in den vergangenen zehn Jahren in Entwick-

lungsprojekten für mechatronische Produkte in den Branchen Automotive, Maschinen-

und Anlagenbau entwickelt und erprobt wurde. Anhand eines Fallbeispiels wird erläutert,

wie ein integriertes Modell aus Rollen, Routinen und Strukturen Projektteams Orientie-

rung, Handlungsspielraum und Ergebnisverantwortung verleiht. Der Beitrag liefert Im-

pulse für ein belastbares, adaptives Projektmanagement in dynamischen Organisations-

umfeldern

Keywords: Post-agiles Projektmanagement, Betriebsmodell, Power Skills, Teamwork,

Product Culture

1 PROJEKTERFOLG GmbH, Am Willgraben 7, 64367 Mühltal, thorsten.nottebaum@projekterfolg.de

230

Oliver Linssen et al. (Hrsg.): Projektmanagement und Vorgehensmodelle,

Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2025 231

Programmmanagement zur Steuerung strategischer Trans-

formationen

Klaus Schopka1