eJournals PROJEKTMANAGEMENT AKTUELL 30/5

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
121
2019
305 Gesellschaft für Projektmanagement

Management von Großprojekten mit Scrum

121
2019
Daniel Jovanovic
In diesem Artikel werden Herausforderungen an Jahrzehnte andauernde Großprojekte dargestellt und mit Lösungsansätzen aus dem agilen Projektmanagement kombiniert. Als zentrales Kernelement dient die Methodik „Scrum“, welche sich beispielsweise an dreißigtägigen Zyklen orientiert. Fazit: Die Integration von Scrum steht vor immensen Herausforderungen; könnte Großprojekten aber langfristig zu einem lang ersehnten Projekterfolg verhelfen.
pm3050056
>> Für eilige Leser In diesem Artikel werden Herausforderungen an Jahrzehnte andauernde Großprojekte dargestellt und mit Lösungsansätzen aus dem agilen Projektmanagement kombiniert. Als zentrales Kernelement dient die Methodik „Scrum“, welche sich beispielsweise an dreißigtägigen Zyklen orientiert. Fazit: Die Integration von Scrum steht vor immensen Herausforderungen; könnte Großprojekten aber langfristig zu einem lang ersehnten Projekterfolg verhelfen. Autor: Daniel Jovanovic 1 Einleitung Oftmals heißt es in Presseberichten und sogar literarischen Werken, Großprojekte sind zum Scheitern verurteilt. Die Fertigstellung eines Großprojektes findet nur selten im Rahmen der geplanten Kostenkalkulation und terminlichen Vorgaben statt. Vielmehr erreichen Großprojekte auf internationaler Ebene Kostenüberschreitungen gegenüber dem ursprünglichen Zielwert von bis zu 1.900 % [1]. Auch auf nationaler Ebene sind Großprojekte zu beobachten, die das ursprünglich gesetzte Ziel nicht erreichen oder nicht erreichen konnten. Dazu zählen beispielsweise Großprojekte, wie das Lkw-Mautsystem Toll Collect, die Elbphilharmonie und der Berliner Flughafen. Derartige Projekte stehen stark im öffentlichen Fokus und sind gleichzeitig durch höchste Komplexität charakterisiert. Der Grund für das „Scheitern“ von vielen Großprojekten ergibt sich genau aus dieser immensen Komplexität. Ziel ist es also, die Komplexität so weit wie möglich zu minimieren und so die Laufzeit des Projektes und die entsprechende Investitionshöhe zu reduzieren. Das klassische Projektmanagement sieht im Rahmen der Betrachtung des magischen Dreiecks eine klare Restriktion vor, dass nur eine Komponente der drei Kategorien Zeit, Kosten und Qualität positiv beeinflusst werden kann. Die Qualität wird durch den Umfang der notwendigen Maßnahmen und die Aufrechterhaltung von Qualitätskriterien festgelegt, die sich außerhalb des magischen Dreiecks befinden (Sicherheit, Effektivität, Effizienz, Minimierung von Betroffenheit etc.). Da die Faktoren und Erfordernisse zur Zielerreichung dieser Qualitätskriterien sich im Laufe eines Großprojektes ändern, ist eine stetige Beachtung von Anforderungen seitens der Stakeholder (Öffentlichkeit, Städte, Kommunen, Private etc.) notwendig. Das klassische Projektmanagement stößt aber genau bei derartinagement dabei umgesetzt werden? Wenn ja, unter welchen Rahmenbedingungen? Als Beispiel wird die agile Arbeitsmethodik „Scrum” ausgewählt und im Rahmen einer Fokussierung auf Großprojekte im Schieneninfrastrukturbereich hinsichtlich ihrer Anwendungstauglichkeit untersucht. 2 Großprojekte Die Forschung begründet das Verfehlen von Projektzielen mit Fehleinschätzungen der Kosten und der Projektdauer bei Projektbeginn, mit möglichen Änderungen von Projektanforderungen, die nicht genügend beachtet werden, und mit Marktentwicklungen, die ebenfalls unterschätzt werden [4]. Die Literatur erfasst folgende Kriterien, die für die Charakterisierung eines Projekts als Großprojekt ausschlaggebend sind [5]:  Zeit: Projektdauer länger als 10 Jahre  Kosten: Projektvolumen größer als 100.000.000 USD  Auftraggeber: öffentlich  Immense Risiken  Soziale, politische, ökonomische und technologische Auswirkungen  Höchstes Maß an Komplexität  Hohe Anzahl an unbeeinflussbaren und externen Projekteinflussgrößen Das Projektmanagement von Großprojekten unterscheidet sich vom Management klassischer Projekte gravierend. Während der Projekterfolg klassischer Projekte im Rahmen der drei bekannten Größen Kosten, Zeit und Qualität gemessen wird, sind die Anforderungen an die Zielerreichung bei Großprojekten viel höher. Neben den sogenannten Key Performance Indicators (KPI), den Kosten, der Zeit und der Qualität werden Performance-Kriterien, wie Effektivität, Effizienz, Sicherheit, Aufrechterhaltung der gen Problemstellungen auf Grenzen. Im Fokus stehen bei Anforderungsänderungen die Zusammenarbeit und Kollaboration zwischen allen Projektbeteiligten, da nur so eine kundenorientierte Lösung im Rahmen des Großprojektes umgesetzt werden kann. Kundenorientierung und Zusammenarbeit sind die Stichwörter, die im agilen Projektmanagement Anwendung finden. Agiles Projektmanagement hat sich mittlerweile bereits über Jahrzehnte in der Branche der Softwareentwicklung bewährt [2]. Auch eine Integration des agilen Projektmanagements in andere Branchen hat in den letzten Jahren stark zugenommen und zu Effizienzeffekten geführt [3]. Was die Projekte in diesen Branchen aber alle gemeinsam haben, sind die vergleichsweise kurze Projektdauer und der vergleichsweise kleine bis mittlere Projektumfang. Doch wie sieht die Anwendungsmöglichkeit des agilen Projektmanagements auf der Großprojektebene aus? Kann agiles Projektma- Management von Großprojekten mit Scrum Funktioniert das? projektManagementaktuell | AUSGABE 5.2019 56 WISSEN Erwartungen der Stakeholder und der Minimierung von konstruktionsbedingten Konflikten und Auseinandersetzungen in der Öffentlichkeit, erfasst. Allein durch die multidimensionale Performance-Messung ergibt sich die hohe Erwartungshaltung auf unterschiedlichen Ebenen bei Großprojekten, die zu entsprechenden Zielverfehlungen führt. Durch die lange Laufzeit von Großprojekten ergeben sich oftmals Änderungen an die Projektanforderungen, die zwar im Rahmen des Projektes aufgegriffen und umgesetzt werden können, aber zu großen Einbußen in mindestens einer der multidimensionalen Performance-Messungskriterien führen. Um diesen Effekt aufzugreifen und die notwendige Flexibilität bei Großprojekten herzustellen, eignet sich das agile Projektmanagement, das im folgenden Kapitel näher erläutert wird. 3 Agiles Projektmanagement mit Scrum Agiles Projektmanagement ist eine Art „Gegenbewegung“, die im Rahmen der Softwareentwicklung in den 90er-Jahren initiiert wurde. Agiles Projektmanagement wird als Gegenbewegung charakterisiert, da zu diesem Zeitpunkt in nahezu allen anderen Industriebereichen der Drang zu standardisierten Prozessen und zum Vermeiden von kurzfristigen Änderungen herrschte. Die Softwareentwicklung stieß allerdings auf Grenzen des klassischen Projektmanagements, da die ständig geänderten Projektanforderungen, die seitens der Kunden festgelegt wurden, zu Projektmisserfolgen führten. Das agile Projektmanagement ist auf derartige Änderungen eingestellt und führt dadurch zu höheren Effizienzergebnissen. Im Laufe der Zeit etablierte sich dieser Grundgedanke auch in anderen Branchen, die sich heutzutage eine individualisierte Massenfertigung in der Produktion, wie beispielsweise in der Automobilindustrie, als Ziel setzen. Das Rahmenwerk „Scrum“, das von Jeff Sutherland im Jahr 1993 auf Basis vorheriger Entwicklungen von Nonaka und Takeuchi entwickelt wurde, dient als elementares Kernelement und repräsentiert das agile Projektmanagement im Rahmen eines inkrementellen Vorgehens [6]. Der große Unterschied zwischen klassischem und agilem Projektmanagement ergibt sich bei der Betrachtung des Arbeitsfortschritts und der „Produktlieferung“. Während beim klassischen Projektmanagement das Produkt am Ende mit all seinen Ausprägungen dem Kunden bereitgestellt wird, ermöglicht die agile Arbeitsweise mit Scrum ein inkrementelles Vorgehen, das nach iterativen Prozessen die Erwartungen des Kunden erfüllt und zu höherer Kundenausrichtung führt. Scrum ist grundsätzlich durch eine einfache Regelhaltung, eine fest strukturierte Meeting-Struktur, wenige und klar definierte Rollen und Verantwortlichkeiten und durch die selbst organisierte Arbeitsform des Scrum-Teams charakterisiert. Die Rollen des Scrum-Teams beschränken sich auf den Product Owner, der die Kundeninteressen vertritt und die Kundenzufriedenstellung verantwortet, den Scrum Master, der für die Einhaltung des Scrum- Rahmenwerks verantwortlich ist, und das „Entwicklungsteam“, das im Rahmen seiner Interdisziplinarität für die Umsetzung des gewünschten Produktes verantwortlich ist. Eine klare Einschränkung ergibt sich bei der Betrachtung der Projektgröße. Die Theorie besagt, dass Scrum nur in kleineren und mittleren Projekten angewandt werden kann, da sonst die Komplexität und die notwendigen Interaktionen nicht mehr greifbar sind. Nach der reinen Lehre ist eine Anwendung von Scrum in einem Großprojekt ausgeschlossen [7]. Dieser Artikel widmet sich dieser Fragestellung und bietet einen Einblick in die Umsetzungsmöglichkeiten von Scrum in Großprojekten. Dabei wird auch auf bestehende Ansätze in der Skalierung von Scrum auf Großprojekte Bezug genommen und auf entsprechende Schwierigkeiten hingewiesen. 4 Herausforderungen und Lösungsansätze Eine immense Herausforderung stellt in erster Linie der zeitliche Aspekt dar. Während sich Großprojekte über Jahrzehnte erstrecken, lebt der Scrum-Ansatz von tagesscharfen Aufgabensteuerungen und Planungen. Folgende Kernfragen stehen im Fokus: Ist eine Integration von Scrum auf Gesamtprojektebene sinnvoll? Ändert sich das Prozesswesen in Großprojekten durch Scrum? Wie passen die zeitlichen Dimensionen von Jahrzehnten und Tagen zusammen? Reichen die bestehenden Skalierungsansätze aus? Die Frage nach der Implementierung auf Gesamtprojektebene kann bereits mit einem klaren „Nein” beantwortet werden. Scrum kann in Großprojekten nur in bestimmten Projektanteilen umgesetzt werden. Die Integration in Großprojekten kann nur erfolgen, wenn gewisse Rahmenbedingungen vorliegen und so die Effizienz und Transparenz von Scrum zum Tragen kommt. Die Paradoxie bei Großprojekten ergibt sich bei der Betrachtung der Komplexität. Während die Anwendung von Scrum in einem komplexen Umfeld angedacht ist [8], stellt der immense Komplexitätscharakter im Rahmen von Großprojekten [9] gleichzeitig die größte Hürde dar. Bei umfangreichen Projekten, die mit einem Scrum- Team nicht bewältigt werden können, schlägt die Literatur die Anwendung von „Scrum of Scrums“ vor [10]. Das Projekt soll mit mehreren Scrum-Teams, autarker Bearbeitungsstruktur und gleichzeitiger Informationsvermittlung zwischen allen Parteien gestemmt werden. Allerdings stößt auch dieses Konzept nach Paasivaara et al. [10] auf seine Grenzen. Der Koordinationsaufwand bei Aufrechterhaltung eines agilen Vorgehens im Rahmen eines Großprojektes auf allen Ebenen ist in der Praxis nicht vertretbar. Ferner erlaubt das Rahmenwerk „Scrum of Scrums“ eine autarke Bearbeitung in interaktiven Teams, jedoch ist die übergreifende Planung und Abstimmung der einzelnen Arbeitsergebnisse wieder als Teilprojekt zu verstehen, bei dem sich der dann vorhandene Komplexitätsgrad widerspiegelt. Ein weiterer Ansatz zur Skalierung von Scrum und Übertragung auf Großprojekte ergibt sich bei der Betrachtung des Rahmenwerks SAFe (Scaled Agile Framework) [11]. Dieses Rahmenwerk fokussiert sich stärker auf die Integration von agilen Methoden in bereits vorhandene klassische Projekt- und Organisationsstrukturen. In dieser Hinsicht ist eine Implementierung von SAFe absolut im Sinne von bestehenden Großprojekten. Die Besonderheit bei diesem Rahmenwerk ergibt sich durch die Existenz eines sogenannten Agile Release Trains (ART). Die Einführung einer solchen Systematik ist mit einem sehr hohen Aufwand verbunden. Der Grund dafür ist, dass der ART auf das Management des Unternehmens ausgerichtet ist, sodass das Management in dem Prozess mit integriert wird und strategische Zielsetzungen auf agiler Arbeitsebene beeinflusst werden. Auf Basis weiterer Scrum-Rollen (Enterprise Architects, Epic Owners, Program Portfolio Manager etc.) wird dann durch eine Anknüpfung an die Lean-Ansätze von Toyota aus den 90er-Jahren ein gesamthaftes Rahmenwerk abgebildet, das sich laut der Literatur erst ab einer Projektgröße von ca. 150 Projektmitarbeitern lohnt und rechnet [12]. Das Rahmenwerk ist projektManagementaktuell | AUSGABE 5.2019 WISSEN 57 in erster Linie für eine projektübergreifende Struktur konzipiert, sodass die Projektperspektive in dem komplexen System verloren geht. In der Literatur taucht ein weiteres Rahmenwerk auf, das auf Basis eines Skalierungsansatzes für die Integration agiler Methoden in Großprojekten infrage kommt. Es handelt sich um den Ansatz „Large Scale Scrum (LeSS)“ [13]. Was ist die Besonderheit und wie unterscheidet sich dieser Ansatz vom klassischen Scrum-Ansatz? Der Ansatz LeSS setzt sich die Erweiterung der Projektbeteiligten mit gleichzeitiger Komplexitätsreduktion zum Ziel. Deshalb wird oft das Motto „weniger ist mehr“ mit diesem Skalierungsansatz in Verbindung gebracht. Die grundsätzliche Vorgehensweise ist analog zum ursprünglichen Scrum-Ansatz zu sehen, jedoch werden parallel laufende und separate Scrum-Teams koordiniert. Der wesentliche Unterschied zum Konzept „Scrum of Scrums“ ergibt sich bei Betrachtung des Product Backlogs. Es ist ein Product Backlog für mehrere Scrum-Teams vorhanden. Die größte Hürde ergibt sich bei der Aufgabenplanung und Koordination der entsprechenden Ergebnisse. Die Aufgaben werden den Teams entsprechend dem jeweiligen Know-how-Gebiet zugeteilt. Der Aufbau zentralisierter Wissensstrukturen ist unumgänglich. Schnell kann ein Konflikt im Bereich des transaktionalen Wissens auftreten, der sich nicht ohne Weiteres beheben lässt. Großprojekte sind in ihrer Komplexität jedoch so verankert, dass das transaktionale Wissen für den Projekterfolg ausschlaggebend ist. Wird die Erstellung eines Produktes hingegen als Ziel genommen, ist ein spartenartiges Denken durchaus möglich, sodass der LeSS-Ansatz im Bereich des Produktmanagements durchaus Anwendung gefunden hat. Die Literatur bietet noch einen weiteren Ansatz zur Integration agiler Strukturen in umfassenden Organisationen. Es ist die Rede von „Nexus“ [14]. Dieser Ansatz ähnelt dem ursprünglichen Scrum-Ansatz am ehesten. Es existiert ein Product Backlog und es können drei bis neun Scrum-Teams koordiniert werden. Der Fokus bei diesem Ansatz liegt auf den Abhängigkeiten zwischen den Teams und der Förderung des Kommunikationsverhaltens in der gesamten Scrum- Organisation. Ein sogenanntes Nexus-Team setzt genau diese Einheiten um und setzt sich dann die Stärkung der Kommunikation und des Wissensaustausches zum Ziel. Die ursprünglichen Rollen werden erweitert. Ein Problem bei diesem Ansatz liegt darin, dass das prozessuale Inkrement im Rahmen der Aufgabenpakete nicht kontinuierlich unter den einzelnen Teams abgestimmt wird. Durch die „Nexus Daily Scrums“, die vor den normalen Daily Scrums der einzelnen Teams durchgeführt werden, werden bewusst Abhängigkeiten identifiziert und die Planung der einzelnen Teams wird dadurch indirekt beeinflusst. Dem „Nexus Integration Team“ als neues Rollenbild obliegt somit in indirekter Weise eine erweiterte Handlungsmacht im Vergleich zu den normalen Scrum-Teams. Alle Skalierungsansätze sind in ihrer theoretischen Natur umsetzbar und können zu Produktivitätsgewinnen im Vergleich zu klassischen Projektmanagementstrukturen führen. Vielmehr stellt sich die Frage, inwieweit bestehende Großprojekte um ein agiles Verhalten ergänzt und teilweise umgewälzt werden können. Das agile Vorgehen orientiert sich nach Faschingbauer [8] an Projektsituationen, bei denen die Anforderungen an das Ziel und die Art der Zielerreichung unklar sind. Bei Großprojekten sind in der Regel die Anforderungen an das Ziel relativ klar, während die Art der Zielerreichung bei vielen Projektbestandteilen in Großprojekten ein Fragezeichen bildet. In Abbildung 1 [8] wird die Situation der Großprojekte nach der „Stacey-Matrix“ in das komplexe Umfeld eingegliedert und bildet somit die Absprungbasis für die Integration von Scrum. Bei den Projektbestandteilen, bei denen die Art der Zielerreichung nicht ganz klar ist, erzielt die agile Arbeitsmethodik ihren positiven Effekt. Die meisten Abläufe sind bei Großprojekten in standardisierte Prozesse eingegliedert und bilden auch einen guten Rahmen für eine erfolgreiche Umsetzung bis zu dem gewissen Bereich der Einordnung von Großprojekten in die Stacey-Matrix (in Anlehnung an Faschingbauer [8]) projektManagementaktuell | AUSGABE 5.2019 58 WISSEN Unkenntnis. Sind Projektbestandteile durch bereits definierte Prozesse zu lösen, schafft agiles Projektmanagement nur in geringem Maße einen Mehrwert. Interessanter ist die Anwendung der Methodik, wenn gewisse Aufgabenstellungen nicht durch unternehmensinterne und standardisierte Prozesse abbildbar sind und ein gewisser Spielraum besteht, der agiles Vorgehen überhaupt zulässt. Neben der Betrachtung des Prozesswesens und entsprechenden Freiräumen für agiles Vorgehen steht auch noch die Frage nach den zeitlichen Dimensionen im Raum. Darin ergibt sich ein weiterer Grund dafür, dass Scrum auf Gesamtprojektebene keinen Mehrwert erzielen kann, sondern vielmehr eine kreative Lösungsmöglichkeit bei kurzzyklischen Projektbestandteilen bietet. Bei der zeitlichen Betrachtung wird schnell ersichtlich, dass ein Product Backlog für ein Großprojekt nicht handhabbar ist. Auch die Fortschreibung und die Detaillierung von User-Stories führen zu erhöhtem Koordinationsaufwand. Je weiter das Großprojekt in seiner Planung und Umsetzung voranschreitet, desto kurzzyklischer werden die Projektaufgaben und Projektbestandteile. Dies steht auch in direktem Zusammenhang mit der Integration von Scrum. Die Schaffung des Mehrwertes kann als exponentiell steigend angenommen werden, da die Anteile an kurzzyklischen Aufgaben und der Anteil an prozessunabhängigen Aufgaben entsprechend zunehmen. Die zeitlich unterschiedlichen Dimensionen zwischen Großprojekten und Scrum sind zwar vorhanden, stellen aber bei Betrachtung des entsprechenden Projektfortschritts keineswegs eine Herausforderung dar. 5 Fazit Großprojekte und Scrum könnten hinsichtlich ihrer zeitlichen Dimensionen kaum unterschiedlicher sein. Großprojekte dauern Jahrzehnte, Scrum orientiert sich an Tagesplanungen. Großprojekte sind von standardisierten Prozessen geprägt, während Scrum ein agiles Vorgehen erfordert. Auf den ersten Blick stehen Scrum und Großprojekte in keinem denkbaren Zusammenhang. Bei genauerer Betrachtung wird aber schnell ersichtlich, dass auch Großprojekte zeitlich voranschreiten und somit kurzzyklische Projektbestandteile und Aufgaben zum Tagesgeschäft gehören. Die Kunst liegt darin, geeignete Projektbestandteile zu identifizieren, die nicht im standardisierten Prozesswesen integriert sind. Derartige Projektbestandteile sollten auch weiterhin von der Notwendigkeit einer tagesscharfen Steuerung geprägt sein. Um die durch Scrum angestrebten Effizienzgewinne zu erzielen, sollten die entsprechenden Projektbestandteile auch einen hohen Komplexitätsgrad haben, der sich durch unklare Anforderungen an das Projektziel und der Unkenntnis der Art der Zielerreichung ergibt. Der im Laufe der Zeit exponentiell steigende Mehrwert durch die Integration von Scrum lässt sich auf die Projektphasen bzw. Leistungsphasen in Großprojekten beziehen und kann so zum Projekterfolg beisteuern. Grundlegend ist also festzuhalten, dass sowohl konventionelle Projektteams als auch Scrum-Teams erforderlich sind. Diese Tatsache führt zu neuen Herausforderungen. Die Organisationsstrukturen müssen in Großprojekten für eine erfolgreiche Integration von Scrum angepasst werden; es sind Anpassungen von Vertragsstrukturen (unternehmensübergreifende Projektteams) vorzunehmen und die Schaffung eines Änderungsbewusstseins wird zu einem zentralen Kernelement. Das konventionelle Management von Großprojekten und das Rahmenwerk Scrum stehen nicht im Widerspruch - sie ergänzen sich vielmehr.  Literatur [1] Flyvbjerg, B. (2014). What you Should Know about Megaprojects and Why: An Overview. In: Project Management Journal, 45(2), 6-19. [2] Fernandez, D.J. & Fernandez, J.D. (2008). Agile Project Management - Agilism versus Traditional Approaches. In: The Journal of Computer Information Systems, 49(2), 10-17. [3] Conforto, E. et al. (2014). Can Agile Project Management be Adopted by Industries Other than Software Devlopment? In: Project Management Journal, 45(3), 21-34. [4] Han et al. (2009). Analyzing Schedule Delay of Mega Project: Lessons Learned From Korea Train Express. In: IEEE Transactions of Engineering Management, 56(2), 243-256. [5] Oliomogbe, G.O. & Smith, N.J. (2012). Value in Megaprojects. In: Organization, Technology and Management in Construction, 4(3), 617-624. [6] Sutherland, J. (2004). Agile Development: Lessons Learned from the first Scrum. In: Cutter Agile Project Management Advisory Service, 5(20), 1-7. [7] Serrador, P. & Pinto, J.K. (2015). Does Agile work? - A quantitative analysis of a agile project success. In: International Journal of Project Management, 33(5), 1040-1051. [8] Faschingbauer, M. (2010). Effectuation: Wie erfolgreiche Unternehmer denken, entscheiden und handeln (Systematisches Management), S. 18-20. [9] Giezen, M. (2012). Keeping it simple? A case study into the advantages and disadvantages of reducing complexity in mega project planning. In: International Journal of Project Management, 30(7), S. 781-790. [10] Paasivaara, M. et al. (2012). Inter-team Inter-team Coordination in Large-Scale Globally Distributed Scrum: Do Scrum-of-Scrums Really Work? In: Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement, S. 235-238. [11] Brenner, R. & Wunder, S. (2015). Scaled Agile Framework - Presentation and Real World Example. In: IEEE Eighth International Conference on Software Testing, Verification and Validation Workshops (ICSTW). [12] Stojanov, I. et al. (2015). A Maturity Model for Scaling Agile Development. In: 41st Euromicro Conference on Software Engineering and Advanced Applications. [13] Larman, C. & Vodde, B. (2016). Large-Scale Scrum: More with LeSS. Addison-Wesly Professional, S. 27. [14] Schwaber, K. (2015). Nexus Guide. The Definitive Guide to Nexus: The exoskeleton of scaled Scrum development. Scrum.org. Schlagwörter agiles Projektmanagement, Großprojekte, Scrum Autor Daniel Jovanovic (M. Sc.) ist derzeit als Projektingenieur, als externer Doktorand im Bereich Technologie- und Innovationsmanagement und als Lehrbeauftragter im Bereich Technologiemanagement tätig. Anschrift: DB Netz AG, Mülheimerstr. 50, 47057 Duisburg, E-Mail: daniel.jovanovic@deutschebahn.com projektManagementaktuell | AUSGABE 5.2019 WISSEN 59