energizing great minds

Hybrides Projekt-management

WHITE PAPER

Die Verbindung von traditionellen und agilen Methoden in Produktentwicklungsprojekten

Udo Leischner Julia Chermette

Dirk Köhne

Alle in diesem Dokument verwendeten Markennamen, Warenzeichen, Produktbezeichnungen, deren Abkürzungen und Logos sind Eigentum der betreffenden Unternehmen und werden als geschützt an- erkannt. Alle durch Dritte geschützte Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts und den Besitzrechten der jeweiligen einge- tragenen Eigentümer. Allein aufgrund der bloßen Nennung ist nicht der Schluss zu ziehen, dass Mar- kenzeichen nicht durch Rechte Dritter geschützt sind.

© CONTACT Software GmbH. Alle Rechte vorbehalten. Nach Redaktionsschluss dieser Schrift können sich noch Änderungen ergeben haben. Alle Angaben ohne Gewähr.

1 Produktentwicklung im Wandel – Markttrends und 4 wachsende Anforderungen

2 Projektmanagement im Überblick 7 Traditionelles Projektmanagement 8 Agile Vorgehensmodelle 8 Wann agil und wann traditionell? 11

3 Besondere Anforderungen in Engineering-Projekten 12 Vorteile agiler Vorgehensweisen 13 Herausforderungen agiler Methoden 14

4 Hybrides Projektmanagement: Die Verbindung 16 traditioneller und agiler Methoden Grundkonzept eines hybriden Projektmanagements 17 5 Erfolgsfaktoren für agiles Vorgehen 19 Fazit 21 6 Glossar 22

7 Quellen 24

Inhalt

Produktentwicklung im Wandel – Markttrends und wachsende Anforderungen

1

5Produktentwicklung im Wandel – Markttrends und wachsende Anforderungen

Produktinnovationen sind für Unternehmen entschei-

dend, um wettbewerbsfähig zu bleiben. Neue Indust-

rie-4.0-Technologien, Data Analytics, der 3D-Druck und

die zunehmende Digitalisierung stellen Unternehmen

vor neue Herausforderungen.

Zum einen werden Produkte immer komplexer, da ein

wesentlicher Anteil der Funktionalitäten durch Software

und Elektronik realisiert wird. Daraus resultiert eine

beschleunigte Funktionsentwicklung und eine große

Funktions- und Variantenvielfalt.

Zum anderen müssen Produkte immer schneller auf den

Markt gebracht werden. Dies führt dazu, dass Entwick-

lungsprojekte begonnen werden müssen, bevor die Pro-

duktanforderungen vollständig bekannt sind, und ohne

dass die erforderliche Technologie voll beherrscht wird.

Die schnellen Veränderungen am Markt setzen Unter-

nehmen unter Druck, sodass Produkte und Geschäfts-

modelle immer häufiger angepasst werden müssen.

Die auftretenden Herausforderungen der globalen Ver-

netzung und zunehmender Digitalisierung, werden auch

mit dem Akronym VUCA beschrieben [1, 2]:

Volatility steht für die schnellen Veränderungen am

Markt.

Uncertainty steht dafür, dass die Zukunft unsicher ist

und Planung sowie Prognosen kaum zu treffen sind.

Complexity steht für die zunehmende Komplexität

durch Globalisierung und Digitalisierung.

Ambiguity steht für mehrdeutige und widersprüchliche

Informationen in Projekten und Unternehmen.

Die Entwicklung in den verschiedenen Domänen

getrennt voranzutreiben und dann erst zu integrieren,

genügt nicht mehr. Vielmehr gilt es, das Produkt von An-

fang an interdisziplinär zu konzipieren, um eine Lösung

aus einem Guss zu erreichen, Integrationsprobleme früh

zu erkennen und gegenzusteuern und somit Risiken zu

minimieren. Dabei setzen Unternehmen methodisch

verstärkt auf Systems-Engineering-Ansätze wie das

Model Based Systems Engineering (MBSE). MBSE ist eine

formalisierte Methode der Modellierung zur Unter-

stützung von Systemanforderungen, Design, Analyse,

Verifikation und Validierung, beginnend in der konzepti-

onellen Entwurfsphase und über die gesamte Entwick-

lungs- und spätere Lebenszyklusphase hinweg [3].

Abbildung 1Anwendungsgebiete agiler

Methoden – Vergleich

2014 und 2016 (Quelle:

eigene Darstellung in

Anlehnung an [4])

100%90%

82%

Software-Entwicklung IT-nahe Themen (bspw. SAP-Projekte) Aktivitäten ohne besonderen IT-Bezug

In welchen Themenbereichen nutzen Sie agile Methoden bzw. agiles Projektmanagement?

21%

40%

27%

34%

80%

60%

40%

20%

0%

2014 n=387 2016 n=720

6 Produktentwicklung im Wandel – Markttrends und wachsende Anforderungen

Unter diesen Bedingungen bergen traditionelle Projekt-

ansätze mit einem von Anfang an hohen Planungsgrad

über das ganze Projekt absehbar massive Probleme.

Denn Änderungen am Projektplan und am Produkt

können später nur mit großem Umplanungsaufwand

vorgenommen werden.

Auch in der Produktentwicklung wird deshalb immer

häufiger auf agile Methoden gesetzt. Deren Einsatz auch

außerhalb der Softwareentwicklung wie beispielsweise

bei IT-nahen Themen steigt seit Jahren kontinuierlich

(siehe Abb. 1). Agile Methoden akzeptieren die Notwen-

digkeit von Änderungen und machen sie zum essen-

ziellen Bestandteil des Vorgehens. Dies erfolgt durch

Kommunikation und interdisziplinäre Zusammenarbeit

zwischen allen Projektbeteiligten. Aber lassen sich die

positiven Erfahrungen aus der Softwareentwicklung

überhaupt auf ein Engineering-Umfeld übertragen?

Diese Frage wird seit einigen Jahren intensiv diskutiert.

Die Einführung agiler Vorgehensweisen stellt einen Pa-

radigmenwechsel dar, der von allen Beteiligten ein Um-

denken verlangt. Zu den Grundvoraussetzungen zählt

der Wille zur kontinuierlichen Veränderung durch das

Lernen aus Fehlern. Eine Reihe von Faktoren erschwert

zumindest die erfolgreiche Adaption agiler Methoden

(siehe Abb. 2).

Mittlerweile kristallisieren sich jedoch erfolgverspre-

chende Herangehensweisen heraus. Dieses White Paper

beschreibt die Verbindung von traditionellen und agilen

Methoden in Engineering-Projekten. Die Grundkonzepti-

onen dieser Synthese basieren auf umfassenden Praxis-

erfahrungen aus der Umsetzung von Anforderungsspe-

zifikationen, Anwender-Interviews sowie der auf diesen

Erfahrungen basierenden Weiterentwicklungen der

Projektmanagementsoftware von CONTACT Software.

Ein bekanntes Beispiel für ein erfolgreiches agiles

Engineering-Projekt ist die von TRUMPF entwickelte

vollautomatische Laserschneidemaschine. Diese Werk-

zeugmaschine wurde komplett agil entwickelt, wobei

von Anfang an Maschinenbauer und Softwareentwickler

in interdisziplinären Teams zusammenarbeiteten [6, 7].

„ Die Entwicklung in den verschiedenen Domänen getrennt voranzutreiben und dann

erst zu integrieren, genügt nicht mehr. Vielmehr gilt es, das Produkt von Anfang an

interdisziplinär zu konzipieren.

Unternehmenskultur passt nicht zu den agilen Werten

Mangelnde Erfahrung mit agilen Methoden

Der Mangel an Managementunterstützung

Fehlende Unterstützung für kulturelle Transition

Inkonsistente agile Praktiken und Prozesse

Druck traditionelle Wasserfallprozesse einzuhalten

Ineffektive Zusammenarbeit des Managements

Allgemeine organisatorische und kommunikative-Probleme

Mangelnde Bereitschaft für Agilität

Unfähigkeit zur kontinuierlichen Priorisierung der Arbeit

Nicht ausreichendes Training

Schlechte Kollaboration und Zusammenarbeit

Weiß nicht 0% 10% 20% 30% 40% 50%

46%

41%

38%

38%

38%

36%

34%

30%

30%

28%

27%

25%

5%

Was erschwert die agile Adaption?

Abbildung 2Die passende Unterneh-

menskultur, Unterstützung

des Managements sowie

gute Zusammenarbeit und

Kommunikation sind

Voraussetzungen für den

Einsatz agiler Methoden

(Quelle: eigene Darstellung

in Anlehnung an [5])

Projektmanagement im Überblick

2

8 Projektmanagement im Überblick

Ein Projekt ist ein einmaliges Vorhaben, welches kon-

stante Bedingungen wie Zielvorgaben sowie zeitliche,

finanzielle und personelle Begrenzungen aufweist [8].

Das Projekt bildet den Anlass und Rahmen aus konkre-

ten Anforderungen, Zielen, Terminvorgaben sowie

Budgets und umfasst alle Aktivitäten, die zum Erreichen

des Projektziels nötig sind: von der Idee bis hin zum

fertigen Produkt. Dabei kommt Anforderungen im

Projektmanagement grundsätzlich besondere Bedeu-

tung zu, weil sie die Entwicklungsziele vorgeben, an

denen sich letztlich der Fortschritt und die Qualität der

Arbeitsergebnisse bemessen lassen. Das Anforderungs-

management ist deshalb die Grundlage für ein erfolgrei-

ches Projektmanagement.

Traditionelles Projekt- managementTraditionelles Projektmanagement beschreibt Vorge-

hensweisen, bei welchen zu Beginn eines Projektes ein

Plan erstellt wird und Abweichungen von Kosten, Zeit

und Umfang so gering wie möglich gehalten werden [9].

Einen Rahmen beziehungsweise ein Projektmuster

schafft in vielen Unternehmen der Produktentstehungs-

prozess (PEP). Der PEP beschreibt den Lösungsweg von

der Kundenanfrage bis zur Inbetriebnahme beim

Kunden in schematischer Form.

Vorteile traditioneller VorgehensmodelleStandards und bewährte Methoden liefern die Grundla-

gen für Musterprozesse eines Projektablaufs. Bei der

Wahl des Modells ist die Projektart entscheidend.

Beispiele für traditionelle Vorgehensmodelle sind unter

anderem das Wasserfallmodell und das V-Modell.

Projekte beruhen in der Regel auf erprobten Vorgehens-

weisen, was die Nutzung von Projektvorlagen ermög-

licht. Die Vorgehensweise bei der Projektabwicklung

kann auf der Basis von Best Practices formalisiert,

wiederholbar gemacht und kontinuierlich verbessert

werden. Diese formalen Standards sind ideal für Unter-

nehmen, die kontinuierlich Produkte entwickeln und

dabei zugleich die Zielsicherheit und Verfahrenskonfor-

mität (Compliance) ihrer Projekte erhöhten wollen.

Grenzen des traditionellen ProjektmanagementsGerade in Entwicklungsprojekten und -prozessen sind

Anforderungen und Lösungen immer häufiger zu Beginn

noch unbestimmt. Geprägt ist die Produktentwicklung

jedoch oftmals von einem erheblichen Aufwand für die

detaillierte Anforderungsklärung (Lastenheft) und die

Projektplanung. Wenn ein komplettes Entwicklungspro-

jekt auf diese Weise mit viel Arbeit und hoher Komplexi-

tät antizipiert wird, ergibt sich ein relativ starres Gerüst,

das zu ändern schwierig und aufwändig ist. Entspre-

chend viel Aufwand fließt dann auch in das Änderungs-

management. Daraus erwächst letztlich eine Tendenz,

spätere Änderungen als Fehler zu betrachten. Nicht

selten führt das jedoch dazu, dass das Team sich stärker

der Planerfüllung verpflichtet fühlt als der Innovation

und der Entwicklung des bestmöglichen Produkts.

Zudem erfolgt die traditionelle Projektplanung in der

Regel nach Domänen gegliedert. Die Spezialisten für

Mechanik, Elektronik und Software neigen ebenso zum

Silodenken wie jene aus zeitlich aufeinanderfolgende

Disziplinen wie Produktentwickler, Prototypenbauer

und Produktionsspezialisten. In einer traditionellen

Projektplanung müssen die Schnittstellen zwischen den

Disziplinen vorausgedacht werden, sodass die verschie-

denen Fachbereiche mit den entsprechenden Schnitt-

stellenanforderungen die Entwicklung isoliert vorantrei-

ben. Angesichts des Regelfalls häufiger Änderungen im

Projektverlauf und anfangs oft gänzlich unklarer Anfor-

derungen liegt es auf der Hand, dass traditionelle

Projektplanung in der Produktentwicklung an ihre

Grenzen kommt.

Agile Vorgehensmodelle

Agile Vorgehensmodelle beschreiben Vorgehensweisen

in der Softwareentwicklung, bei welchen der Fokus auf

die entstehende Software, selbstorganisierte Teams

und kontinuierliches Mitwirken der Anwender und/oder

Kunden gelegt wird. Anforderungen werden im Verlauf

des Projekts nach Bedarf detailliert und umgesetzt.

Agile Methoden und Praktiken verzichten auf eine strikte

Trennung von Planung und Ausführung.

Charakteristisch für agiles Projektemanagement ist:

■ Häufiges Liefern und Demonstrieren von Zwischen-

ergebnissen

„ Anforderungen sind die Grundlage für erfolgreiches Projektmanagement.

9Projektmanagement im Überblick

■ In kurzen Abständen auf Ergebnisse zurückblicken

und daraus lernen

■ Konzentration auf das Wesentliche

■ Fortlaufendes Korrigieren und (Re-)Priorisieren

■ Förderung der Zusammenarbeit im interdisziplinä-

ren Team

■ Förderung von Innovation und Trial & Error

Grundsätze agilen VorgehensAus der Erfahrung, dass komplexe Software-Entwick-

lungsprojekte mit einem deterministischen Projekt-

management-Ansatz nur sehr schwer zu beherrschen

sind, sind in den 90er Jahren agile Vorgehensweisen

gewachsen. Nicht selten sind große Softwareprojekte

gescheitert. Aus dieser Not heraus wurde das Vorgehen

bei der Softwareentwicklung verändert und auf eine

detaillierte Festlegung der Anforderungen und der Pro-

jektplanung verzichtet. Der Begriff „agil“ wurde 2001 bei

einem Treffen in Utah geprägt, auf dem auch das Agile

Manifest formuliert wurde [10]: „Wir erschließen bessere

Wege Software zu entwickeln, indem wir es selbst tun

und anderen dabei helfen. Durch diese Tätigkeit haben

wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen stehen über Prozessen

und Werkzeugen

Funktionierende Software steht über einer umfassen-

den Dokumentation

Zusammenarbeit mit dem Kunden steht über der

Vertragsverhandlung

Reagieren auf Veränderung steht über dem Befolgen

eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite

wichtig finden, schätzen wir die Werte auf der linken

Seite höher ein.“

Die Autoren des Agilen Manifests verwerfen klassische

Methoden wie Planung, Dokumentation und Prozessein-

haltung nicht grundsätzlich. Sie antworten aber auf die

Gefahr, dass diese Methoden leicht zum Selbstzweck

werden und so das eigentliche Ziel aus den Augen

verloren wird. Das Agile Manifest betont, dass das Pro-

dukt wichtiger ist als der Plan. Änderungen sollten als

notwendig und wertvoll betrachtet und begrüßt werden

(Embrace Change) [11]. Um Änderungen produktiv

nutzen zu können, darf der Plan nicht zu detailliert

sein. Agile Methoden sehen eine relativ grobe Planung

für das Gesamtprojekt vor. Es ist wichtig, eine Produkt-

vision oder ein Produktziel zu formulieren und darauf

aufbauend eine Vorstellung zu entwickeln, in welchen

Schritten das Ziel erreicht werden kann. Eine Feinpla-

nung erfolgt dann „auf Sicht“, das heißt bezogen auf

einen Zeithorizont, der gut überschaubar ist und in dem

voraussichtlich keine Änderungen eintreten werden. Bei

der Planung sollte auf Arbeitsergebnisse hingearbeitet

werden, die einen Mehrwert für den Kunden bieten.

Zwei der populärsten agilen Methoden stellen wir im

folgenden Abschnitt kurz vor.

ScrumDie meist kleinen Entwicklungsteams agieren bei Scrum

eigenverantwortlich und selbstorganisiert. Nach dem

Pull-Prinzip entscheidet das Entwicklungsteam selbst,

wie viele Aufgaben innerhalb eines Sprints erledigt

werden. Diese bilden das Sprint Backlog. Wichtig ist

dabei, dass die Aufgaben innerhalb des Zyklus auch

abgeschlossen werden (time boxing). Die Erledigung der

Aufgaben während des Sprints wird auf einem Sprint

Board visualisiert. Das Ziel jedes Sprints ist ein nutz-

bares Ergebnis, welches den Vorgaben des Projektes

gerecht wird [12, 13]. Die Scrum-Meetings schaffen

Transparenz innerhalb des Teams und auch zwischen

„ Das agile Manifest betont: Das Produkt ist wichtiger als der Plan – Planung und Prozesse dürfen nicht zum Selbstzweck werden

Product Owner (PO)

Team

ScrumMaster (SM)

Product Backlog Sprint Planning Sprint Backlog Sprint Produkt

Daily Srum Meeting

Sprint 2 bis 4 Wochen

Abbildung 3Scrum Flow (Quelle:

eigene Darstellung)

10 Projektmanagement im Überblick

Team und Stakeholder und tragen zur Verbesserung der

Kommunikation bei [12]:

Sprint Plannings: Das Team verständigt sich mit dem

Product Owner über die zu realisierenden Funktionalitä-

ten und plant die dazu erforderlichen Aufgaben.

Daily Scrum: Tägliche kurze Meetings verbessern die

Kommunikation innerhalb des Teams deutlich. Die

Teammitglieder tauschen den aktuellen Stand der

Arbeit aus.

Backlog Grooming: Das Projektteam arbeitet am

gemeinsamen Verständnis über die zu entwickelnden

Funktionalitäten.

Sprint Review: Am Ende eines Sprints findet ein Review

mit Projektteam und Kunde statt. Dabei wird über das

aktuelle Inkrement des Produktes diskutiert.

Sprint Retrospektive: Das Team hinterfragt in einer

Retrospektive die eigene Arbeit, um sie zu verbessern.

Scrum-Teams greifen häufig auf weitere agile Techniken

zurück, zum Beispiel für Anforderungsmanagement

(User Storys) und Aufwandschätzung (Planning Poker)

[12].

KanbanUrsprünglich kommt die Kanban-Methode aus dem

Toyota-Produktionssystem und hat das Ziel einen

gleichmäßigen Fluss (Flow) in der Fertigung herzustellen

und Lagerbestände zu reduzieren. In der Softwareent-

wicklung leitet sich die Methode nicht direkt aus dem

Toyota-Produktionssystem ab. Die Methode basiert auf

verschiedenen Modellen wie Lean Product Develop-

ment und Theory of Constraints. Ziel ist dabei, mit Hilfe

von Visualisierung und Limitierung von Aufgaben den

Arbeitsprozess kontinuierlich zu verbessern. Wie in ei-

nem Produktionsprozess sollen Engstellen erkannt und

durch Prozessverbesserungen behoben werden. Diesem

Ziel dienen die folgenden Kanban-Merkmale [14]:

Visualisierung: Auf einem Kanban-Board werden der

Workflow, die vorhandene Arbeit (Tickets) sowie Proble-

me visualisiert.

Limitierung Work in Progress (WIP): Die Anzahl der

Tickets wird limitiert. Eine neue Aufgabe wird erst in

Bearbeitung genommen, wenn eine andere abgeschlos-

sen ist.

Kontinuierlicher Flow: Der Arbeitsfluss ist ein beson-

ders wichtiger Bestandteil von Kanban. Tickets sollen

gleichmäßig durch das System „fließen“, um einen

möglichst effizienten Arbeitsprozess zu erreichen.

Kontinuierliche Verbesserung: Kanban ist ein evolutio-

närer Prozess. Problemstellen im Prozess werden trans-

parent gemacht. Dank des kontinuierlichen Arbeits-

flusses und fortlaufender Optimierungsschritte und

deren Verifikation wird die Prozesseffizienz schrittweise

verbessert [14, 15].

Anwendungsfelder und Bewertung agiler MethodenDie Studie „Digital Engineering – Agile Produktent-

wicklung in der deutschen Industrie“ zeigt, dass in der

Produktentwicklung immer häufiger agile Methoden

eingesetzt werden. Sie basiert auf einer Befragung von

500 Führungskräften, die für das Thema Digitalisierung

verantwortlich sind. Die Ergebnisse belegen, dass

Unternehmen mit agilen Methoden innovativer sind,

mehr Technologien nutzen und ihre Mitarbeiter öfter

weiterbilden [16].

Anwender bewerten die Erfolgsquote agiler Methoden

im Vergleich zu traditionellen Methoden deutlich positi-

ver. Dies geht aus der Studienumfrage „Status Quo Agile

2016/2017“ von Professor Komus von der Hochschule

Koblenz mit über 1000 internationalen Teilnehmern her-

vor [4]. Die Teilnehmergruppe setzte sich unter anderem

aus IT/Software-Bereich (21%), Hightech/Elektronikin-

dustrie (6%) und Automobilindustrie (6%) zusammen.

Von allen Teilnehmern gaben 26 % Software/IT-Ent-

wicklung und 8 % Produktentwicklung als Tätigkeitsbe-

reich an. Das größte Anwendungsfeld finden die agilen

Methoden in der Softwareentwicklung. Im Vergleich zur

letzten Umfrage von 2014 gibt es aber in Themen ohne

IT-Bezug einen deutlichen Zuwachs von Anwendungen

agiler Methoden (siehe Abb. 1).

Sehr verbreitet ist eine selektive Anwendung agiler Tech-

niken. Gründe für selektive Anwendung liegen häufig

in Rahmenbedingungen und Unternehmensvorgaben.

Als am erfolgreichsten werden die durchgängig agilen

Projekte beurteilt. Rund 93% der Befragten stellten

durch agile Methoden eine Ergebnis- und Effizienzver-

besserung fest. Für nahezu alle Anwender überwiegen

die Vorteile durch die Verbesserungen den Aufwand

einer Einführung von agilen Methoden. Scrum wird mit

85% als meistgenutzte Methode genannt, gefolgt von

Kanban, Lean und DevOps [4].

11

Im Rahmen der Konferenz „Agile PEP Minds 2016“

wurde eine Umfrage mit 178 Teilnehmern zum Thema

„Perspektiven agiler PEP 2016“ durchgeführt, die auf den

Fortschritt agiler Projektmanagement-Methoden bei

der Produktentwicklung abzielte. Die unterschiedlich

großen Unternehmen stammen aus verschiedenen In-

dustriezweigen wie Maschinen- und Anlagenbau (30%),

Automobil und Automotive (20%) sowie Elektronik

und Elektrotechnik (18%). Die Umfrage ergab, dass die

häufigste Problemstellung bei Entwicklungsprojekten

mit 71% unklare Produktanforderungen sind. Weitere

Probleme sind unter anderem: Over-Engineering, zu

viele oder ineffiziente Meetings, Kommunikationspro-

bleme, Aufgabenflut, Multitasking sowie unklare oder

nicht eingehaltene Verantwortlichkeiten oder Wissens-

verschwendung [17].

Die Bewertungen der Methoden im Vergleich brachte

bemerkenswerte Ergebnisse: Außer bei den Kriterien

„Planungssicherheit“ und „Genauigkeit der Bewertung

der Fortschritte“ schnitten die agilen Methoden in allen

Teilbewertungen besser ab als das klassische Projekt-

management. Die agilen Methoden Scrum und Kanban

schnitten sogar bei diesen Teilbewertungen besser ab

als die Anwender der klassischen Methode (siehe Abb.

4). Zusätzliche Experteninterviews im Mai und Juni 2018

bestätigten diese Ergebnisse: Anwender von agilen

Methoden sind in jeder Phase des PEP zufriedener oder

zumindest gleich zufrieden wie Anwender klassischer

Methoden [18].

Wann agil und wann traditionell?Eine Einordnung des Projektes hinsichtlich der geeigne-

ten Vorgehensweise kann mit der sogenannten Stacey-

Matrix erfolgen. Diese klassifiziert Projektvorhaben in

vier Komplexitätsbereiche von einfach bis chaotisch.

Einflussgrößen dafür sind einerseits die Klarheit des

Ziels, also der Anforderungen, und andererseits der Grad

des Wissens über den Lösungsansatz, zum Beispiel der

zu verwendenden Technologie:

Einfach: Anforderungen und Lösungsansatz sind

bekannt und klar.

Kompliziert: Anforderungen und/oder Lösungsansatz

sind nur teilweise bekannt und klar.

Komplex: Anforderungen und/oder Lösungsansatz sind

unklar.

Chaotisch: Anforderungen und Lösungsansatz sind

unklar.

Einfache und komplizierte Projekte können in der Regel

mit traditionellen Methoden gut beherrscht werden.

Agile Vorgehensweisen bringen hier nicht notwendi-

gerweise ein besseres Projektergebnis, die Wahl der

Methodik sollte an den Bedürfnissen des Teams und der

Stakeholder orientiert werden. Je unklarer Anforderun-

gen und/oder Lösungsansatz sind, also in Projekten, die

als komplex oder sogar chaotisch klassifiziert sind, desto

mehr ist davon auszugehen, dass Agilität entscheidende

Vorteile hinsichtlich des Projekterfolgs bringt.

komplex

traditio

nal

agil

kompliziert

einfach

chaotischun

klar

,m

ehrd

eutig

klar

,ei

ndeu

tig

klar, bekannt,bewährt

unklar,unerprobt

Anfo

rder

unge

n

Lösungsansatz

Abbildung 5Die Stacey-Matrix

klassifiziert Projekte in

Komplexitätsgrade

(Quelle: eigene Darstellung

in Anlehnung an [19])

100%

80%

60%

40%

20%

0% Erge

bnis

qual

ität

Team

wor

k

Plan

ungs

sich

erhe

tit

Gesc

hwin

digk

eit

Prod

ukte

infü

hrun

gsze

it

Fähi

gkei

t zur

Inno

vatio

n

Gena

uigk

eit d

er B

ewer

tung

der

For

tsch

ritte

Gesa

mte

Lei

stun

gsfä

higk

eit d

er M

etho

de

Bewertung agiler Methoden im Vergleich mit klassischem Projektmanagement

Scrum Kanban DevOps Lean Klassisches Projektmanagement

Projektmanagement im Überblick

Abbildung 4Zusammenfassende

Bewertung der agilen

Methoden durch

Anwender (Quelle: eigene

Darstellung in Anlehnung

an [4])

12

Besondere Anforderungen in Engineering-Projekten

3

13Besondere Anforderungen in Engineering-Projekten

Es liegt in der Natur der Sache, dass Produktentwick-

lungsprojekte einen starken Produktbezug haben.

Voraussetzung für deren effiziente Steuerung ist, dass

die Zusammenhänge zwischen Aufgaben, offenen Punk-

ten und Meilensteinen einerseits und dem Produkt und

seinen Komponenten andererseits für alle Beteiligten

jederzeit bekannt sind. Gegenstand des Entwicklungs-

projekts ist schließlich das Produkt in seinen unter-

schiedlichen Darstellungsformen und Sichten – von

Anforderungen und Funktionen über Zeichnungen,

Modelle und Stücklisten bis hin zu Prüfergebnissen,

Simulationen und Prototypen.

Die Anforderungen an erfolgreiche Produktentwick-

lung sind heute höher als jemals zuvor: unter anderem

aufgrund des kontinuierlich steigenden Elektronik- und

Softwareanteils, des rasanten Technologiefortschritts

und immer kürzerer Produktlebenszyklen sowie der zu-

nehmenden Anzahl funktionaler und zielgruppenspezi-

fischen Produktvarianten (siehe Abb. 2). Angesichts die-

ses Komplexitätsniveaus – siehe auch Stacy-Matrix (Abb.

5) – versprechen sich immer mehr Unternehmen Abhilfe

durch agile Vorgehensweisen. Vor dem Hintergrund des

großen Bedarfs beziehungsweise der bereits vielfach

praktizierten Anwendung in der Produktentwicklung ist

eine genauere Betrachtung der Vorteile sowie etwaiger

Probleme oder spezieller Herausforderungen agiler

Projektmanagementmethoden aufschlussreich.

Vorteile agiler Vorgehens-weisenAuch in der Fertigungsindustrie sind Projekte zuneh-

mend von Unsicherheiten hinsichtlich unklarer Anforde-

rungen und von zahlreichen Änderungen der Kun-

denspezifikationen im Verlauf der Entwicklung geprägt.

Die Vorteile agiler Ansätze liegen daher auf der Hand.

Anforderungen im Projektverlauf konkretisierenAnforderungen vorab nur grob festzulegen und dafür zu

sorgen, dass sie im Lauf des Projekts konkretisiert und

auch geändert werden können, ist eine bewährte

Herangehensweise agiler Methoden aus dem Software-

bereich. Die Ausrichtung am Produktfortschritt, re-

gelmäßige Priorisierung und optimierte Teamkommu-

nikation durch Team-Rituale wie Daily Meetings oder

Reviews sorgen auch im Engineering für eine kontinuier-

liche Reflexion und Weiterentwicklung der Produktan-

forderungen und -lösungen. Die erst im Lauf des Pro-

„ Der PEP basiert auf dem Wissen aus vie-len vorangegangen Projekten und enthält viel Know-how zum optimalen Vorgehen für die Entwicklung des jeweiligen Produkts.

Neue Technologien & Industrie 4.0

• Wirksamere Innovationsprozesse• Neue Geschäftsmodelle

Steigende Anforderungen

• Diversi�kation nach Zielgruppen• Strenge Compliance- Vorschriften• Funktionale Ansprüche

Hoher Kostendruck

Komplexitätbeherrschen

Globale Märkte & Internationalisierung

• Emerging Markets• Lokale Richtlinien und Anforderungen

Kürzere Produkt-Lebenszyklen

• Reduzierung des Time-to-Market• Schnellere Anpassungen und Updates

Innovation durch Software

• Zunahme der E/E-Wertschöpfung• Unterschiedliche Release-Zyklen• Versteckte Abhängigkeiten

• Frühe funktionale Validierung• Digitale Simulation und Analyse

Abbildung 6Eine Vielzahl von Faktoren

und deren Wechselwir-

kung untereinander

kennzeichnen die hohe

Komplexität von

Produktentwicklungspro-

jekten (Quelle: eigene

Darstellung)

14 Besondere Anforderungen in Engineering-Projekten

jekts mit zunehmendem Projektwissen zu treffenden

Entscheidungen werden dann nicht mehr als Korrektur

einer fehlerhaften Planung empfunden, sondern als

Fortschritt im Projektreifegrad.

Dabei wird das Team auch in die Lage versetzt, Lösun-

gen auszuprobieren und ohne großen Verlust wieder

verwerfen zu können. Eine domänenübergreifende

Zusammenarbeit im Team ermöglicht die kurzfristige

Erzeugung von Prototypen, wo sonst Abteilungsgrenzen

überwunden werden müssten. Projektteams und ihre

einzelnen Mitglieder treffen daher selbständig Entschei-

dungen, wo sie in traditionellen Umgebungen auf die

Entscheidung des Projektleiters, vom Plan abweichen zu

dürfen, warten würden. Dies fördert Innovation und

Selbstwirksamkeit des Teams.

Interdisziplinäre und domänenübergreifende Teamarbeit Die Grundausrichtung agiler Methoden auf inter-

disziplinäre Teamarbeit ist äußerst hilfreich, die Kom-

munikation im Projekt zu fördern und eine bessere Basis

für Innovation und höhere Effizienz zu schaffen. Wenn

zum Beispiel bei einem Anlagenbauer die Konstrukteure

zum Daily Meeting in die Werkstatt kommen, liegt eine

Effizienzverbesserung auf der Hand. Die Monteure

können konstruktionsbedingte Probleme im persönli-

chen Gespräch adressieren, anstatt einen formalen

Problembericht in die Konstruktionsabteilung schicken

zu müssen.

Ebenso vorteilhaft ist das agile Prinzip cross-funktiona-

ler Zusammenarbeit: Die verschiedenen Entwicklungs-

domänen von Mechanik über Elektronik bis hin zur

Software arbeiten im agilen Idealfall von Anfang an eng

zusammen. Das Produkt wird so ganzheitlich entwi-

ckelt. Auch wenn Vieles erst im Verlauf des Projekts

konkretisiert wird, werden Änderungsbedarfe an den

Schnittstellen viel frühzeitiger erkannt und können

leichter umgesetzt werden, als wenn dies erst bei einer

späten Integration geschieht.

Herausforderungen agiler MethodenDoch stoßen agile Methoden in Reinform in Enginee-

ring-Projekten auch auf Grenzen, die nicht einfach

durchbrochen werden können. Deshalb ist es oft nur

eingeschränkt möglich, die in Softwareprojekten erfolg-

reich eingesetzten Methoden 1:1 zu übertragen.

Standards und Vorgaben im Produktentwick-lungsprozessIn vielen Unternehmen existiert ein Produktentste-

hungsprozess, dessen Standards und Vorgaben aus

einer Reihe von Gründen eingehalten werden müssen.

Der PEP basiert zum einen auf dem Wissen aus vielen

vorangegangen Projekten und enthält viel Best-Practice-

Know-how zum optimalen Vorgehen für die Entwicklung

des jeweiligen Produkts. Zudem sorgen Prozessvorlagen

dafür, dass Vorgaben von außen einfach eingehalten

werden. Der standardisierte PEP ermöglicht darüber

hinaus, dass die verschiedenen Entwicklungsprojekte

gemeinsam und nach denselben Prinzipien gesteuert

werden können. Nicht zuletzt sorgt die Vergleichbarkeit

dafür, dass aus der Gesamtheit der vergangenen Projek-

te für die Zukunft gelernt werden kann und Verbesserun-

gen in alle weiteren Projekte einfließen.

Agilität versus Prozesssicherheit Planvorgaben und Regularien des klassischen PEP

scheinen auf den ersten Blick dem flexiblen, agilen Vor-

gehen zu widersprechen. Doch verwirft selbst das agile

Manifest die Planung keineswegs, sondern verlangt

vielmehr, dass die Änderungsbereitschaft wichtiger ist

als das Einhalten eines Plans.

Der scheinbare Zielkonflikt agilen Vorgehens und

verlässlicher Rahmenplanung lässt sich auflösen:

Wenn man den PEP als Rahmenplanung versteht, die

wichtige Inhalte vorgibt und zum Beispiel die Quality

Gate-Meilensteine als Etappenziele für das agile Vorge-

hen formuliert, kann man unterhalb dieser Ebene agil

arbeiten und so sowohl vom PEP als auch vom agilen

Vorgehen profitieren. Die Möglichkeiten der Kombina-

tion traditioneller und agiler Vorgehen werden weiter

unten im Rahmen des hybriden Projektmanagements

detailliert erläutert.

„ Der scheinbare Zielkonflikt agilen Vorge-hens und verlässlicher Rahmenplanung

lässt sich elegant auflösen.

15Besondere Anforderungen in Engineering-Projekten

Projektdauer und IterationslängenDie Entwicklungszeit physischer Produkte ist oft sehr viel

länger als bei Software-Releases. Physische Produkte

müssen von vornherein bis zu einer Ausbaustufe entwi-

ckelt werden, die bei einer Software erst nach mehreren

Update-Auslieferungen erreicht wird. Eine Produktent-

wicklung dauert also vielleicht zwei Jahre statt wie bei

einer Software nur drei Monate. Bei Iterationszyklen von

zwei bis vier Wochen kann die Fokussierung verloren

gehen, wenn das Team auf ein so weit entferntes Ziel

hinarbeitet. Diesem Problem kann man begegnen,

indem Entwicklungsprojekte beispielsweise in Quartals-

etappen aufgeteilt werden, in denen jeweils ein be-

stimmtes, wichtiges Projektziel angestrebt wird. Das

Team erreicht dann wieder die Ausrichtung auf das

jeweilige, in Reichweite liegende Etappenziel.

Wenn Sonderteile mit längerem Vorlauf bestellt werden

oder teure Werkzeuge von vornherein „passen“ müssen,

sind diese Sachverhalte als Randbedingung (Constraint)

vorab zu definieren. Dadurch entstehende Termine

können in der Rahmenplanung berücksichtigt werden,

innerhalb derer agil gearbeitet werden kann. So ist

es möglich sicherzustellen, dass die entsprechenden

Aufgaben im agilen Prozess priorisiert und rechtzeitig

erledigt werden.

Teamarbeit und Kommunikation fördernIn vielen Unternehmen erfolgt die Produktentwicklung

in Teams, die weltweit über verschiedene Standorte

verteilt sind. Um die dadurch entstehenden kommuni-

kativen Defizite zumindest annährend kompensieren

zu können, sind regelmäßige Teammeetings besonders

wichtig für die Arbeitskoordination. Die Nutzung eines

agilen Software-Tools ist hier ebenso Pflicht wie der

Einsatz moderner Kommunikationslösungen vom Chat

über Screensharing bis zu Videokonferenzsystemen.

Eine Empfehlung für agile Softwareentwicklung ist,

dass die Entwickler eines Teams Vollzeit für dieses eine

Projekt arbeiten und nicht in verschiedenen parallelen

Projekten beteiligt sind. Die Realität in Entwicklungs-

projekten für physische Produkte ist häufig eine andere.

Entwicklungsingenieure arbeiten beispielsweise an

einer Vielzahl von Variantenentwicklungen mit oder

Qualitätsbeauftragte sind in eine größere Zahl von

Projekten involviert. Diese Mitarbeiter benötigen neben

den üblichen Projekt-Taskboards auch Sichten, die ihre

Aufgaben aus verschiedenen Projekten zusammenfas-

sen. Sie können nicht an allen Meetings der verschiede-

nen Projekte teilnehmen und es wäre ineffizient, ständig

zwischen den verschiedenen Projektboards hin und her

wechseln zu müssen. Hierfür werden Team-Boards, zum

Beispiel für Fachabteilungen, und persönliche Boards

benötigt, die die Aufgaben aus den verschiedenen Pro-

jekten gesammelt anzeigen.

16

Hybrides Projektmanagement: Die Verbindung traditioneller und agiler Methoden

4

17Hybrides Projektmanagement: Die Verbindung traditioneller und agiler Methoden

Agile Methoden bringen auch in der Produktentwicklung

entscheidende Impulse zu höherer Änderungsbereit-

schaft, mehr Ergebnisorientierung und flexibler Reakt-

ionsmöglichkeiten auf geänderte oder neue Situation-

en. Zugleich wird deutlich, dass das Engineering auch

Herausforderungen bereithält, auf die agile Vorgehens-

weisen anzupassen sind. Hybrides Projektmanagement

kombiniert verschiedene Managementmethoden in-

nerhalb eines Projekts. Traditionelle Methoden wie das

Wasserfallmodell lassen sich so mit agilen Methoden

wie Scrum kombinieren. Diese Flexibilität ermöglicht

eine beschleunigte und effizientere Projektdurchfüh-

rung.

Grundkonzept eines hybri-den ProjektmanagementsEiner der zentralen Punkte dabei: Ein Widerspruch

zwischen dem traditionellen, vorausgeplanten Ansatz

einer PEP-Planung und der agilen Vorgehensweise

besteht – wie oben bereits angeführt – bei genauer

Betrachtung beider Ansätze nur dem Anschein nach.

Will man die Vorzüge beider Vorgehensweisen gleicher-

maßen ausschöpfen, sind die Ansätze konzeptionell

jeweils auf ihren Wesenskern zu reduzieren: Wie lassen

Definition Entwurf Umsetzung Test Einsatz

Projekt

Agiles Vorgehen

Klassische Rahmenplanung

Abbildung 7Hybrides Projektmanage-

ment kombiniert klas-

sische Rahmenplanung

(Termine, Ressourcen,

Meilensteine) mit agilen

Vorgehensweisen z.B.

nach Scrum in der eigent-

lichen Entwicklungsarbeit

(Quelle: eigene Darstel-

lung)

sich verlässliche Rahmenplanung und agiles und

flexibles Vorgehen konfliktfrei kombinieren? Indem

beide Ansätze dann und dort zum Einsatz kommen, wo

ihre jeweiligen Stärken liegen.

Verschiedene Umsetzungsmöglichkeiten hybrider MethodenSo kann eine Top-down-Rahmenplanung Prozesssi-

cherheit sowie die Vergleichbarkeit von Meilensteinen

und Qualitätskriterien sicherstellen. Innerhalb dieses

Rahmens kann die Entwicklungsarbeit mit den vorge-

gebenen Etappenzielen bottom-up agil organisiert sein

und so für kurze Feedback-Schleifen, Stakeholder-Ein-

bindung und flexible Reaktionsmöglichkeiten sorgen

(siehe Abb. 10). Doch ist dies nicht die einzige Möglich-

keit hybriden Vorgehens.

Eine hybride Projektorganisation bietet auch die

Möglichkeit, dass verschiedene Teams unterschiedlich

arbeiten. Ein Team, das etwa einen innovationsgetrie-

benen Teilbereich bearbeitet, tut dies agil, während ein

anderes Team einen Standardumfang im selben Projekt

traditionell plant und steuert. Eine solche Aufteilung ist

auch sinnvoll, wenn beispielsweise der Kern-Use-Case

eines Projekts gut bekannt ist und durchgeplant werden

kann, während es Ideen gibt, mit derselben Technologie

18 Hybrides Projektmanagement: Die Verbindung traditioneller und agiler Methoden

noch weitere, aber weniger gut verstandene Use Cases

adressieren zu können, die also besser agil angegangen

werden sollten.

Methodenmix im Gesamtprojekt oder in Projektteilen Andere hybride Projekte zeichnen sich durch unter-

schiedliche methodische Ansätze für die verschiedenen

Phasen des Projekts aus – zum Beispiel, indem die

Anforderungsermittlung auf agile Weise so weit vor-

angetrieben wird, sodass anschließend eine komplett

durchgeplante Umsetzung des Projekts möglich wird. Es

gibt auch Beispiele für Projekte, die traditionell starten

„ In vielen Projekten gibt es sowohl Teilbe-reiche, die gut traditionell durchgeführt wer-

den können, als auch solche, für die ein agiles Vorgehen angebracht ist. Hybrides Vorgehen ermöglicht den passenden Zuschnitt für jede

Projektsituation.

und dann im Verlauf zu agilen Methoden wechseln. Dies

ist beispielsweise der Fall, wenn die Zielsetzung nicht so

gut verstanden wird wie geglaubt, und die Planung so

nicht einzuhalten ist.

Bestenfalls mit Methodenbaukasten Kombinationen der unterschiedlichen Vorgehens-

modelle zeigen, dass die Entscheidungskriterien der

Stacey-Matrix (siehe Abb. 9) nicht nur auf ganze Projekte,

sondern ebenso gut auf Einzelumfänge innerhalb eines

Entwicklungsprojekts angewandt werden können. In

vielen Projekten gibt es sowohl Teilbereiche, die gut

traditionell durchgeführt werden können, als auch sol-

che, für die ein agiles Vorgehen angebracht ist. Hybrides

Vorgehen ermöglicht den passenden Zuschnitt für jede

Projektsituation. Optimal ist es, über einen Methoden-

baukasten zu verfügen, aus dem Projektleiter und (Teil-)

Team gemeinsam schöpfen und die für sich optimale

Vorgehensweisen wählen und kombinieren können.

Diesen Ansatz hat beispielsweise das Corporate Project

Management der Robert Bosch GmbH mit seinem “Four

Flavors of Agility” Model gewählt [20].

Abbildung 8 Mit hybriden Methoden

Planung und Ausführung

verbinden: Traditionell

top-down Termine und

Meilensteine planen – und

bottom-up agile- und

selbstorganisierte

Teamarbeit (Quelle:

eigene Darstellung)

Wertschöpfung

Management

Planen, steuern

ausführen

TOP-

DOW

N

BOTTOM

-UP

19

Erfolgsfaktoren für agiles Vorgehen

5

Erfolgsfaktoren für agiles Vorgehen20

In der Entwicklung physischer Produkte ist eine große

Vielzahl an aufwachsenden Produktdaten zu berück-

sichtigen oder als Arbeitsergebnis zu erzeugen: vom

Lastenheft, Richtlinien und Normen über Konzepte,

Berechnungen und Simulationsergebnisse bis hin zu

3D-Modellen und Zeichnungen. Product Lifecycle Ma-

nagement (PLM) umfasst die ganzheitliche Verwaltung

dieser Daten und Informationen − aber nicht nur das.

Ganzheitliches PLM beinhaltet ebenso die Fähigkeiten,

den Prozess der Bearbeitung und Verteilung zu steuern

und zu kontrollieren – was den Projektmanagement-

aspekten der Produktentwicklung entspricht. Zusam-

menfassend lassen sich im Hinblick auf die Anforderung,

zumindest partiell agil in Produktentwicklungsprojekten

vorgehen zu können, drei Schlüsselfaktoren herausstel-

len.

1. Zentrale Datenbasis für PLM und die Projekt- organisation: „Single Source of Truth“

Aus dem ganzheitlichen PLM-Verständnis heraus

ist es bei einigen Unternehmen seit Jahren be-

währte Praxis, das Projektmanagement in das PLM-

System zu integrieren, statt unverbunden neben-

einanderstehende Systeme für Produktdaten und

Projektmanagement zu betreiben, wie es noch

häufig anzutreffen ist. Die Projektbeteiligten sollten

jederzeit sowohl über die aktuell gültigen Produkt-

als auch Projektdaten verfügen und zwischen

beiden Perspektiven wechseln können, ohne den

Kontext zu verlieren.

Dafür steht der Begriff „Single Source of Truth“: für

eine zentrale Datenbasis, die natürlich die Produkt-

daten beinhaltet, sie aber auch in den Kontext der

Projektprozesse einordnet. So können Anwender

beispielsweise zu einer Projektaufgabe direkt

die erforderlichen Produktdaten einsehen und

bearbeiten, oder umgekehrt von einer Baugruppe

direkt die zu erledigenden Aufgaben sehen. Diese

zentrale Datenbasis ist sowohl die Grundlage der

Datenverwaltung im Rahmen des PLM als auch

der Projektorganisation. Ebenso lässt sich im Daily

Meeting das passende Modell zu einer Aufgabe

aufrufen - und zwar unmittelbar und ohne Suchauf-

wand. Lieferergebnisse lassen sich direkt abbilden

und visualisieren. Die Zeit, die die Mitarbeiter bei

der Informationssuche sparen, gewinnen sie für

ihre eigentliche Arbeit – die Entwicklung innovati-

ver Produkte.

2. Agiles Vorgehen im Rahmen etablierter PEP-Leitplanken Wie oben dargelegt, ist der kombinierte Einsatz von

traditionellen und agilen Projektmanagementme-

thoden eine Antwort auf die Herausforderungen,

vor denen Engineering-Projekte heute stehen.

Dabei gilt es, mit einem projektspezifisch hybriden

Mix Prozesssicherheit einerseits und Agilität ande-

rerseits so zu verbinden, dass die Vorteile beider

Methoden optimal zur Geltung kommen. Ein essen-

zieller Aspekt im Konzept von CONTACT Software

ist dabei, die Top-down-Managementsicht mit der

Bottom-up-Ausführungssicht zu verbinden. Dabei

ist das PLM-integrierte Projektmanagement mit

Zugriff auf alle relevanten Aufgaben, Termine und

Ergebnisse ein Schlüsselfaktor unseres Ansatzes.

Bewährte Planungs- und Steuerungsmechanismen

traditioneller Vorgehensweisen des „klassischen“

PEP (V-Modell, Wasserfallmethode) schaffen

sichere Leitplanken – innerhalb derer die Teams

agil nach Scrum oder Kanban vorgehen können.

Unterstützt durch Elemente wie Task Boards und

Activity Streams arbeiten Entwickler effizient und

abgestimmt. Die Kombination der jeweils passen-

den Methoden sorgt für eine deutliche Beschleuni-

gung des Projektfortschritts.

3. Agile Werkzeuge für verteilte Arbeitsorgani-sation in der Produktentwicklung

Die agile Arbeitsorganisation aus der Softwareent-

wicklung lässt sich nicht 1:1 auf Engineering-Umge-

bungen übertragen. Im IT-Umfeld steht die Forde-

rung nach einer dedizierten Projektzuordnung der

Mitarbeiter im Raum. Produktentwickler hingegen

müssen damit zurechtkommen, dass sie weltweit

verteilt und in der Regel in mehreren Projekten

„ Softwareunterstützung für Engineering- Projekte sollte eine Auswahl des methodisch

passenden Vorgehens und Zugriff auf die Pro-duktdaten im Projektkontext ermöglichen.

21Erfolgsfaktoren für agiles Vorgehen

zugleich arbeiten. Dem müssen die agilen Soft-

ware-Werkzeuge Rechnung tragen, indem sie den

Fachteams und den einzelnen Mitarbeitern deren

Aufgaben aus verschiedenen Projekten in speziel-

len agilen Sichten aufbereiten, sodass Transparenz

und Anschaulichkeit auch im Multiprojektumfeld

nicht verloren gehen.

Jedes Fachteam muss seine Aufgaben aus den

Projekten in einem Team-Board durchsprechen

und jeder Mitarbeiter seine Aufgaben agil auf einem

persönlichen Board überblicken und abarbeiten

können, ohne zwischen den Boards der verschie-

denen Projekte hin- und herspringen zu müssen.

Bestenfalls sorgen zudem Social-Media-Funktionen

wie Activity Streams für maßgeschneiderte Infor-

mationsversorgung und inklusive Kontextbezug.

Fazit

Agile Methoden sind kein Allheilmittel, um den Heraus-

forderungen in der Produktentwicklung – Digitalisierung,

technologischer Wandel und volatile Märkte – zu begeg-

nen. Aber sie können entscheidende Vorteile bringen, um

den Entwicklungsprozess im Griff zu behalten. Auch wenn

es durchaus möglich ist, Engineering-Projekte komplett

agil durchzuführen, dürfte in der Mehrzahl der Projekte

eine kluge Kombination aus traditionellem PEP und dem

gezielten Einsatz agiler Methoden zum Erfolg führen.

Der etablierte PEP bietet einen prozesssicheren Rahmen

und Vergleichbarkeit innerhalb des Projektportfolios. Die

Agilität innerhalb dieser Leitplanken hilft, auf unsicherem

Terrain effizient im interdisziplinären Team voranzukom-

men.

Im Engineering sind jedoch weitere Rahmenbedingungen

zu beachten, um agile Vorgehensweisen zielsicher und

erfolgreich nutzen zu können. Hier ist die Integration von

Projektprozessen und Produktdaten entscheidend, damit

Mitarbeiter im Kontext agiler Aufgaben unmittelbar und

ohne großen Suchaufwand auf die benötigten Produkt-

daten zugreifen können. Dabei ist es erforderlich, mit

passenden Sichten Transparenz und agile Bearbeitung

auch für Multiprojektbeteiligte zu gewährleisten.

Softwareunterstützung für Engineering-Projektmanage-

ment sollte also sowohl die Auswahl der methodisch je-

weils passenden Vorgehensweise ermöglichen und dabei

agile Inhalte auch für Multiprojektkontexte in geeigneter

Weise aufbereiten als auch integrierten Zugriff auf die

Produktdaten im Projektkontext bieten.

ProduktPortfolio vernetzt

Prozesse mechatronisch

Aufgaben mechanisch

ProjektKollaboration

UnternehmenStandorte

Mitarbeiter

Abbildung 9 Engineering-Projekte stellen hohe Anforderungen an IT-Unterstützung: Es gilt,

Projektprozesse zu planen, steuern und auszuführen, Zusammenarbeit zu unter-

stützen und zudem Zugriff auf aufwachsende Produktdaten zu ermöglichen

(Quelle: eigene Darstellung)

22

Glossar

6

Agile VorgehensmodelleAgile Vorgehensweisen legen den Fokus auf das zu

entwickelnde Produkt, Selbstorganisation des Ent-

wicklungsteams und kontinuierliches Mitwirken der

Anwender.

Hybrides ProjektmanagementHybrides Projektmanagement kombiniert verschiedene

Managementverfahren innerhalb eines Projektes. Tradi-

tionelle Methoden wie das Wasserfallmodell können mit

agilen Methoden wie Scrum kombiniert werden.

KanbanKanban zählt zu den agilen Vorgehensmodellen. Durch

Visualisierung (Kanban-Board) des Arbeitsflusses und

Limitierung der Menge angefangener Arbeit (WIP-Limit)

wird der Arbeitsfluss transparent gemacht und kann

durch das selbstorganisierte Team kontinuierlich ver-

bessert werden.

Model-based Systems Engineering (MBSE)MBSE ist eine formalisierte Methode der Modellierung

zur Unterstützung von Systemanforderungen, Design,

Analyse, Verifikation und Validierung, beginnend in der

konzeptionellen Entwurfsphase und über die gesamte

Entwicklungs- und spätere Lebenszyklusphase hinweg.

Product Lifecycle Management (PLM)PLM ist ein Managementansatz und umfasst die ganz-

heitliche Verwaltung aller Daten und Informationen,

die bei der Entwicklung neuer oder der Aktualisierung

bestehender Produkte erstellt und verteilt werden.

Außerdem beinhaltet PLM die Fähigkeit, den Prozess der

Bearbeitung und Verteilung unternehmensübergreifend

zu steuern und zu kontrollieren. Eine PLM-Lösung ergibt

sich aus dem Zusammenwirken von Menschen, Arbeits-

weisen, Modellen und IT-Werkzeugen.

Produktentstehungsprozess (PEP)Der PEP beschreibt den Lösungsweg von der Kundenan-

frage bis zur Inbetriebnahme beim Kunden in schema-

tischer Form. Dabei liefern Standards und bewährte

Muster wie das V-Modell Grundlagen für Projektmuster.

ProjektmanagementProjektmanagement dient dazu, Projekte strategisch

und effizient zu steuern, zu planen und zu überwachen.

Es beinhaltet Richtlinien, organisatorische Strukturen,

Prozesse und Methoden.

Traditionelles ProjektmanagementTraditionelles Projektmanagement beschreibt Vorge-

hensweisen, bei welchen zu Beginn eines Projektes ein

Plan erstellt wird und Abweichungen von Kosten, Zeit

und Umfang so gering wie möglich gehalten werden.

ScrumScrum ist eine aus der Software-Entwicklung stammen-

de Methode des agilen Projektmanagements. Komplexe

Projekte werden in mehrere zwei- bis vierwöchige

Zwischenergebnisse zerlegt und regelmäßig Kunden/An-

wendern präsentiert. Entwickelt wird in kleinen selbst-

organisierten Teams.

VUCADas Akronym VUCA (Volatility, Uncertainty, Complexity

and Ambiguity) steht für Herausforderungen des politi-

schen, ökonomischen, ökologischen und gesellschaftli-

chen Wandels wie globaler Vernetzung und zunehmen-

der Digitalisierung.

Glossar 23

24

Quellen

7

Quellen 25

[1] Dr. Georg Angermeier, VUCA. https://www.projektmagazin.de/glossarterm/vuca [Aufruf: 13.11.2018].

[2] Susanne Grätsch, Kassandra Knebel (2017): Change Management in unserer VUCA Welt: Die Erfolgsfaktoren.

https://www.berlinerteam.de/magazin/change-management-vuca-welt-definition-modelle-erfolgsfaktoren/ [Aufruf:

13.11.2018].

[3] MBSE Wiki. http://www.omgwiki.org/MBSE/doku.php#mbse_wiki [Aufruf: 13.11.2018].

[4] Prof. Ayelt Komus (2017): Abschlussbericht: Status Quo Agile 2016/2017. 3. Studie über Erfolg und Anwendungsfor-

men von agilen Methoden. Hochschule Koblenz, University of Applied Sciences

[5] SCRUMevents: Agile Leadership & Organisationsentwicklung. https://www.scrum-events.de/agile-leadership-or-

ganisationsentwicklung.html [Aufruf 23.01.2019]

[6] Heinz Erretkamps: Komplexe Produktentwicklungen mit Agile und Lean beschleunigen. In ProjektMagazin

05/2018.

[7] Digitalisierung konkret: L26 - wie eine deutsche Wundermaschine die Arbeit revolutioniert. In Stern online 7.1.2018

und Printausgabe 1/2018.

[8] Deutsches Institut für Normung (DIN) (2009), DIN 69901:2009 Teil 1-2: Projektmanagement – Projektmanagement-

systeme.

[9]Dr. Georg Angermeier, Traditionelles Projektmanagement. https://www.projektmagazin.de/glossarterm/traditio-

nelles-projektmanagement [Aufruf: 13.11.2018].

[10] agilemanifesto.org: Manifest für Agile Softwareentwicklung. http://agilemanifesto.org/iso/de/manifesto.html

[Aufruf: 13.11.2018].

[11] agilemanifesto.org: Prinzipien hinter dem Agilen Manifest. http://agilemanifesto.org/iso/de/principles.html

[Aufruf: 13.11.2018].

[12] Boris Gloger (2017): Scrum in der Hardwareentwicklung. https://borisgloger.com/wp-content/uploads/2014/07/

Whitepaper-Hardware.pdf?882268 [Aufruf: 13.11.2018].

[13] Scrum-Master.de Agiles Projektmanagement. http://scrum-master.de/Scrum-Einfuehrung [Aufruf: 13.11.2018].

[14] Wikipedia: Kanban (Softwareentwicklung). https://de.wikipedia.org/wiki/Kanban_(Softwareentwicklung) [Aufruf:

13.11.2018].

[15] it-agile.de: Einstieg und Überblick Kanban. https://www.it-agile.de/wissen/einstieg-und-ueberblick/kanban/

[Aufruf: 13.11.2018].

[16] Dr. Axel Pols und Karl Osti (2017): Digital Engineering – Agile Produktentwicklung in der deutschen Industrie.

Berlin, 2017.

[17] Perspektiven Agiler PEP 2016, (2016): Agile meets Projektmanagement & Produktentwicklung Umfrage.

[18] idw – Informationsdienst Wissenschaft: Auch in der Produktentwicklung: Verbesserte Zufriedenheit mit agilen

Methoden und Lean. https://idw-online.de/de/news701454 [Aufruf: 23.01.2019]

[19] Dr. Georg Angermeier, Stacey-Matrix. https://www.projektmagazin.de/glossarterm/stacey-matrix [Aufruf:

13.11.2018].

[20] Stephan Wohlfahrt, Dr. Thilo Köder: HYBRID POWER. PROJEKTMANAGEMENT IM WANDEL. Vortrag auf der PM

Welt, München am 13.03.2018

contact-software.com