Add Thesis

Going Agile: Challenges Encountered when Embracing Agile Project Management

Written by Anonymous

Paper category

Master Thesis

Subject

Business Administration>General

Year

2017

Abstract

Masterarbeit: Seit dem Jahrtausendwechsel hat sich das agile Projektmanagement als Mittel zur Bewältigung des sich ständig verändernden Geschäftsumfelds durchgesetzt. Obwohl die Zahl der Unternehmen, die den Übergang vollzogen haben, gestiegen ist, ist die wissenschaftliche Literatur in diesem Bereich noch immer spärlich. Ziel dieser Arbeit ist es daher, zu untersuchen, welche Herausforderungen das agile Projektmanagement mit dem Übergang vom traditionellen zum agilen Projektmanagement verbindet. Um dies zu untersuchen, wird eine Einzelfallstudie bei ArlaFoods durchgeführt, die sich mitten in der Umstellung von agilem Projektmanagement auf traditionelles Projektmanagement befinden. Mit Hilfe eines ethnographischen Ansatzes werden halbstrukturierte Interviews, Feldnotizen und Beobachtungen während eines einmonatigen Zeitraums am Hauptsitz von ArlaFoods in Aarhus, Dänemark, durchgeführt. Die Ergebnisse dieser Fallstudie zeigen, dass viele APM-Herausforderungen explizit mit dem Einsatz von APM zusammenhängen, während andere Herausforderungen durch den Wechsel der Methodik entstehen und auf den Übergang vom traditionellen Projektmanagement zum agilen Projektmanagement zurückzuführen sind. Diese Studie konnte eine Reihe von Herausforderungen identifizieren, die im Gegensatz zu früheren Erkenntnissen nicht explizit mit APM verbunden sind, sondern im Zusammenhang mit dem Übergang von traditionellem zu agilem Projektmanagement auftreten. Damit trägt sie mit neuen Erkenntnissen zum bestehenden Forschungsportfolio über agiles Projektmanagement bei. Da die Technologie fortschreitet und zu einem immer wichtigeren Bestandteil des Geschäftsumfelds wird, müssen Unternehmen kontinuierlich mit den Technologien Schritt halten, um nicht ihren Wettbewerbsvorteil und damit Marktanteile zu verlieren. Geschäftsbezogene Innovationen wie die Analyse und Verarbeitung von Daten, die Gewinnung von Erkenntnissen, die Unternehmen bei der Vorhersage und dem Verständnis der Kundennachfrage und des Kundenverhaltens helfen, sind Beispiele für Fortschritte, die Unternehmen dazu zwingen, die Art und Weise, wie sie ihre Geschäfte führen, zu überdenken. Daher wird ein Projektmanagementmodell, das diesen Fortschritten gerecht wird, für Organisationen immer wichtiger (Comella-Dorda, Lohiya, & Speksnijder, 2015).Projektmanagement bezieht sich auf eine Reihe von Richtlinien, die erklären und definieren, wie ein bestimmtes Projekt verwaltet wird (Špundak, 2014). Somit kann der Begriff Projektmanagement als eine Reihe von Prozessen, Methoden, Regeln und Vorlagen definiert werden, die durch einen Rahmen dargestellt werden, der während des Lebenszyklus eines Projekts angewendet werden kann. Ein Projektmanagement-Ansatz, der aufgrund des zunehmenden Einflusses der Technologie übernommen wurde, ist das agile Projektmanagement (im Folgenden APM), das um die Jahrtausendwende populär wurde und sich zu einem leistungsstarken Instrument für Organisationen entwickelt hat, um die operative Schnelligkeit und Effizienz zu steigern und gleichzeitig Kosten zu senken (Ika, 2009; Shenhar, 2004). Lee und Xia (2010, S. 90) nennen als Merkmale von APM: "kurze, inkrementelle, iterative, zeitlich begrenzte Entwicklungszyklen, selbstorganisierende Teams, aktive Beteiligung der Stakeholder und kontinuierliche Lieferung funktionierender Software". Neben APM gibt es eine Reihe von Projektmanagementtechniken, die von Befürwortern von APM häufig als "traditionelles Projektmanagement" (im Folgenden TPM) bezeichnet werden. Aus der Perspektive der APM-Theoretiker werden hier Projektmanagementtechniken, die nicht agil sind, auf der Grundlage einer Reihe gemeinsamer Merkmale behandelt, die nach Sutherland & Ahmad (2011) TPM kennzeichnen. Im Gegensatz zu den sequenziellen und weniger flexiblen Merkmalen von TPM ist die Popularität von APM eine Reaktion auf die Forderung nach größerer Anpassungsfähigkeit und schnelleren Entscheidungsprozessen in Organisationen. In der Softwareentwicklung ist APM nützlich, da es die Softwareentwicklungsteams in die Lage versetzt, den Endnutzer zu integrieren und kontinuierlich auf Anforderungsänderungen zu reagieren (Dingsøyr & Lassenius, 2016), was sich von TPM unterscheidet, bei dem die Anforderungen vor dem Projektstart vorgelegt werden. APM ermöglicht auch Flexibilität in dem Sinne, dass die Teams nicht mehr an lange Projektlebenszyklen gebunden sind und daher in der Lage sind, auf sich ändernde Anforderungen zu reagieren (Augustine 2005, Stavru, 2014, Boehm & Turner 2005). Die gegensätzlichen Merkmale von TPM und APM führen zu einer Reihe von potenziellen 2Herausforderungen, wenn IT-Abteilungen und Organisationen gleichermaßen auf APM umstellen. In vielerlei Hinsicht können die unterschiedlichen Merkmale als Gegensätze betrachtet werden, die von Teammitgliedern und Managern ein Umdenken in Bezug auf ihre Arbeitsweise erfordern (Špundak, 2014).1.2 ProblemstellungNach Serrador & Pinto (2015) werden Projekte in Billionenhöhe investiert. Leider ist die Misserfolgsquote beträchtlich, was bedeutet, dass wertvolle Ressourcen und Zeit verloren gehen, aber sie stellen fest, dass APM einen positiven Einfluss auf den Projekterfolg hat. Daher kann das Wissen und die Kenntnis der Herausforderungen, die bei der Umstellung auf und der Anwendung von APM auftreten können, die Erfolgsquote von Projekten verbessern. Welche Rückschläge haben Gruppen, die mit APM arbeiten, zu überwinden? Wo sind die Projektteams im Rückstand? Und welche unvorhergesehenen Herausforderungen können durch ein größeres Bewusstsein für häufige und wiederkehrende Herausforderungen und Fallstricke bewältigt werden? Herausforderungen und Erfolgsfaktoren wurden bereits erforscht (Judgev & Müller, 2005; Chow & Cao, 2008; Hoda & Murugesan, 2016; Conforto et al., 2015; Dingsøyr & Lassenius, 2016), aber oft beziehen sich die Ergebnisse explizit auf APM. Immer mehr Projektgruppen und Organisationen beginnen, APM zu adaptieren (Conforto et al., 2014). In der bisherigen Forschung wurde jedoch kaum berücksichtigt, dass der Übergang von TPM zu APM einen Einfluss darauf haben könnte, warum die Herausforderungen auftreten. Da sich APM und TPM beispielsweise in den Bereichen Entscheidungsfindung, Selbstorganisation, Projektplanung und Projektdurchführung unterscheiden, könnten einige Herausforderungen tatsächlich eine Folge der veränderten Arbeitsweise der Mitarbeiter sein. Bannink (2013) geht auf einige Herausforderungen beim Übergang von Wasserfall- zu Scrum-Methoden ein, wobei Wasserfall eine Unterform von TPM und Scrum eine Unterform von APM ist (Einzelheiten dazu in Kapitel 2).Bannink (ebd.) nennt die Erleichterung der Managerrolle, das Fehlen einer Befehls- und Kontrollstruktur und die Befähigung selbstorganisierender Teams als einige der wichtigsten Herausforderungen, die bei diesem Übergang auftreten. Chen, Ravichandar & Procter (2013) führen ebenfalls Untersuchungen durch, wobei sie sich auf den Übergang von traditionellen zu agilen Produktentwicklungsmethoden beschränken. In ihrer Studie werden zwei große Herausforderungen festgestellt: die Entwicklung neuer Managementpraktiken, die für die Methode geeignet sind, und die Unterstützung der Geschäfts- und Entwicklungsabteilungen bei der Übernahme der Methode. Obwohl es bereits einige Untersuchungen zu den Herausforderungen im Zusammenhang mit dem Übergang gibt, betonen Bannink (2013) und Chen, Ravichander & Proctor (2013), dass weitere wissenschaftliche Untersuchungen zu diesem Thema durchgeführt werden müssen. 3Die zunehmende Popularität von APM (Lee & Xia, 2010) impliziert die Notwendigkeit zu verstehen, welche Herausforderungen explizit mit APM verbunden sind und welche Herausforderungen das Ergebnis alter Gewohnheiten sind, die sich nur schwer ändern lassen. Beim Übergang von TPM zu APM lebt die sequenzielle und hierarchische Denkweise in den Mitarbeitern weiter. Darüber hinaus zeigen verschiedene Ergebnisse (Hoda & Murugesan, 2016; Conforto et al., 2016; Joslin & Müller, 2015; Stettina & Hörz, 2015), dass Projekterfahrung ein Schlüsselfaktor für den Gesamterfolg von APM ist. Erfahrung führt also zu einem besseren Verständnis dafür, welche Herausforderungen im Rahmen von APM auftreten und wie diese zu bewältigen sind. Darüber hinaus stellen Stettina & Hörz (2015) fest, dass APM-Erfahrung allein nicht ausreicht, um APM ausreichend zu implementieren. Die Herausforderungen liegen im Silo-Denken, in der Ressourcenzuteilung und die Anpassung von APM erfordert Struktur, Zeit und gut durchdachte Routinen, um den Kulturwandel durchzusetzen.1.3 ZielsetzungDer Zweck dieser Arbeit ist es, zu untersuchen, ob zuvor identifizierte Herausforderungen innerhalb von APM auf den Übergang von TPM zu APM zurückzuführen sind oder ob die Herausforderungen, wie die bisherige Forschung nahelegt, explizit mit APM verbunden sind. Durch die Untersuchung der am häufigsten genannten APM-Herausforderungen auf verschiedenen Ebenen einer Organisation - Organisationsebene, Teamebene und individuelle Ebene - soll diese Arbeit zusätzliche Informationen zu den Herausforderungen des APM in der Softwareentwicklung liefern, indem sie aufzeigt, ob APM-Herausforderungen die Folge eines Übergangs sind. 1.4 ForschungsfragenUm den Zweck dieser Arbeit zu erfüllen, wird die folgende Forschungsfrage gestellt:-Welche APM-Herausforderungen können mit dem Übergang von TPM zu APM in Verbindung gebracht werden?Die Beantwortung dieser Frage kann wertvoll sein für: -Praktiker, die den Übergang von TPM zu APM vollziehen oder planen -Theoretiker, die auf dem Gebiet des APM forschen 42 Theorie- und LiteraturübersichtDieses Kapitel soll einen Überblick darüber geben, was in der akademischen Welt in Bezug auf das Thema der Arbeit diskutiert wird. Es bildet auch die Grundlage für den analytischen Rahmen am Ende dieses Kapitels. Der analytische Rahmen wird als Grundlage und Bezugspunkt für die folgenden Abschnitte dienen. Zunächst wird in diesem Kapitel erläutert, wie APM-Theoretiker TPM sehen. Anschließend wird erläutert, was APM ist und wie es als Alternative zu TPM funktionieren kann. Schließlich wird erläutert, welche Herausforderungen im Zusammenhang mit APM in der wissenschaftlichen Literatur am häufigsten genannt werden.2.1. Was bedeutet TPM für APM-Theoretiker?Es gibt keine einheitliche Definition oder Kennzeichnung von TPM. Innerhalb von TPM gibt es eine Reihe von Variationen, die in der Forschung und in Literaturübersichten auftauchen. Aufgrund des Umfangs und des Zwecks dieser Arbeit wird in diesem Abschnitt erläutert, was traditionelles Projektmanagement in der Softwareentwicklung aus der APM-Perspektive bedeutet.2.1.1 Variationen von TPM innerhalb der IT.TPM geht davon aus, dass Ereignisse, die das Projekt beeinflussen, wie Planung, Ausführung und Geschäftsanforderungen, vorhersehbar sind und dass die verwendeten Aktivitäten und Werkzeuge leicht zu verstehen sind (Hass, 2007). Das bedeutet, dass TPM Gewissheit, Stabilität und eine einfache Kontrolle der bestehenden Prozesse voraussetzt. Ein linearer Ansatz ist der Wasserfallansatz (Ibid), der für das Management von IT-Projekten verwendet wird und bei dem der Fortschritt als stetig fließender Wasserfall durch die verschiedenen Phasen des Projekts betrachtet wird. Der Übergang von einer Phase zur nächsten in einer sequentiellen Reihenfolge bedeutet, dass das Projekt die nächste Phase erreicht, wenn die vordefinierten Meilensteine oder Ziele der vorhergehenden Phase erreicht sind (Ramesh et al., 2012; Wysocki, 2009).Darüber hinaus wird nach Abschluss jeder Phase eine Dokumentation über die Meilensteine der Arbeit erstellt, um den Fortschritt darzustellen. Da der Wasserfall-Ansatz linear ist, wird er starr und ist nicht unbedingt für alle IT-Projekte geeignet. Der Wasserfall-Ansatz kann jedoch inkrementell verwendet werden, was bedeutet, dass die Entwicklungsphasen mehr als einmal durchgeführt werden können (Sheffield & Lemétayer, 2013). Obwohl die inkrementelle Alternative einem vorgegebenen Plan folgt, kann sie im Vergleich zum linearen Ansatz als flexibel angesehen werden, da sie den Entwicklern mehrere Auslieferungen ermöglicht, während der lineare Ansatz die Entwickler auf eine einzige Auslieferung beschränkt (siehe Anhang: Abbildung 1 und Abbildung 2) (ebd.). Beide TPM-Ansätze 5 folgen einem im Voraus festgelegten Projektplan, was sie starr macht. Die Vorteile von TPM liegen also darin, dass die anstehenden Schritte klar definiert sind und klar ist, was getan werden muss, um voranzukommen (Hass, 2007). Die Hauptnachteile bestehen darin, dass die zugrundeliegenden Annahmen einen Verlust an Flexibilität und eine eingeschränkte Möglichkeit bedeuten, in vergangenen Phasen zurückzugehen und zu korrigieren oder zu aktualisieren. Dies bedeutet auch, dass das Modell wenig Spielraum für den Umgang mit ungeplanten Ereignissen, wie z. B. Änderungen der Nutzeranforderungen, lässt (ebd.). 2.1.2 Welche Merkmale definieren TPM?In Wirklichkeit gibt es keine einzelne Projektmanagementmethode mit dem Namen TPM. Dies ist eine Bezeichnung, die von APM-Befürwortern vergeben wird, um eine Gruppe von Methoden zu unterscheiden, die auf der Grundlage einer gemeinsamen Reihe von Merkmalen nicht agil sind. Zum Beispiel charakterisieren Sutherland & Ahmad (2011) TPM als nicht-iterativ, phasenweise, sequenziell und plangesteuert.Špundak (2014) geht von denselben Merkmalen aus, fügt aber bei der Definition von TPM den Begriff hierarchisch hinzu.Darüber hinaus meinen APM-Theoretiker, dass TPM einer Reihe von standardisierten Prozessen folgt, indem sie die Idee der Planung und rigorosen Wiederverwendung unterstützen, um die Entwicklung zu einer effizienten und vorhersehbaren Tätigkeit zu machen (Boehm, 2002; de Carvalho, Patah, & Bido, 2015; Joslin & Müller, 2015; Wysocki, 2007). Beim TPM wird davon ausgegangen, dass es eine Reihe von Problemen gibt und dass es für jedes Problem optimale und vorhersehbare Lösungen gibt (Dybå, 2000; Nerur, Mahapatra, & Mangalaraj, 2005). Nach Špundak (2014) gewährleisten Projektmanagementmethoden, die nicht dem APM-Modell folgen, Robustheit und Anwendbarkeit für ein breites Spektrum von Projekten, von einfachen und kleinen bis hin zu großen und komplexen Projekten. Die Prämisse von TPM ist, dass Projekte einfach, vorhersehbar und linear sind. Darüber hinaus folgt TPM einem klar definierten Zeit-, Budget- und Umfangsrahmen, der auch als Eisernes Dreieck bezeichnet wird - ein Modell, das zur Visualisierung der Beschränkungen eines Projekts verwendet wird (de Carvalho, Patah, & Bido, 2015) (siehe Anhang, Abbildung 3).Das Eiserne Dreieck verdeutlicht die Projektbeschränkungen und zeigt, dass eine Beschränkung nicht geändert werden kann, ohne eine andere zu beeinflussen. Daher zielt TPM darauf ab, die Effizienz und Optimierung der ursprünglichen Projektpläne zu erreichen, indem das Projekt innerhalb der Grenzen des Eisernen Dreiecks abgeschlossen wird (Wysocki, 2007; Špundak, 2014; Conforto et.al. 2014).Auch wenn die expliziten Begriffe, die bei der Beschreibung von TPM verwendet werden, variieren können, ist das Wesentliche dasselbe; nach Ansicht der APM-Theoretiker bedeutet TPM den nicht-iterativen, phasenweisen, sequenziellen, plangesteuerten, hierarchischen, standardisierten und vorhersehbaren Prozess des Managements eines Projektlebenszyklus. Diese werden in Tabelle 1 näher erläutert. 6Tabelle 1. Identifizierte Merkmale von TPM.2.2. Was ist APM?Verschiedene Erkenntnisse (Hoda & Murugesan, 2016; Conforto et al., 2016; Joslin & Müller, 2015; Stettina & Hörz, 2015) zeigen, dass Projekterfahrung ein Schlüsselfaktor für den Gesamterfolg von APM ist. Erfahrung führt zu einem besseren Verständnis dafür, welche Herausforderungen im Rahmen von APM auftreten und wie man sie bewältigen kann. Um also richtig einschätzen zu können, wann ein Übergang zu APM sinnvoll sein könnte, um zu verstehen, warum bestimmte Herausforderungen auftreten können oder welche Herausforderungen zu erwarten sind, muss man verstehen, was APM ist. Eine funktionierende Software ist wichtiger als eine umfassende Dokumentation. Die Zusammenarbeit mit den Kunden ist wichtiger als Vertragsverhandlungen. Die Reaktion auf Veränderungen hat Vorrang vor der Befolgung eines vordefinierten Plans (Fowler & Highsmith 2001, S. 2). Seit der Einführung von APM hat sich die Managementmethode weiterentwickelt, und es sind Untertechniken und andere Variationen erschienen, die den Grundsätzen von APM folgen, zum Beispiel: Scrum, 7Kanban, eXtreme Programming(XP) und Continuous Deployment(Denning, 2015). APM hat an Popularität gewonnen und wird als entscheidend für die Wettbewerbsfähigkeit in der Softwareentwicklungsbranche angesehen (Lee & Xia, 2010). Für Praktiker ist Scrum die beliebteste Technik, während andere Methoden immer weniger genutzt werden (Dingsøyr & Lassenius, 2016; Schwaber & Beedle, 2001). Erickson et al. (2005) behaupten, dass APM ein Mittel ist, um so viel wie möglich von der Schwerfälligkeit und Standardisierung, die üblicherweise mit TPM in der Softwareentwicklung assoziiert wird, zu entfernen, um eine schnelle Reaktion auf sich ändernde Umgebungen, Änderungen der Benutzeranforderungen, beschleunigte Projektfristen usw. zu fördern. Lee & Xia (2010, S. 90) stellen fest: "Agilität ist das Herzstück der Prinzipien und Praktiken der agilen Entwicklung". Im Anschluss an diese Aussage nennen Lee & Xia (ebd.) die Merkmale, auf denen APM aufbaut: "kurze, iterative, zeitlich begrenzte Entwicklungszyklen, selbstorganisierende Teams, aktive Beteiligung von Interessengruppen und kontinuierliche Bereitstellung funktionierender Software." Im Folgenden wird ein Überblick über die Merkmale von APM gegeben, um zu verdeutlichen, auf welchen Ideen APM aufbaut.IterativDybå & Dingsøyr (2008) beschreiben APM als iterativ und inkrementell und versuchen, die standardisierten Ansätze im Zusammenhang mit TPM zu vermeiden. Iterationen sind kurze und schnelle Zyklen innerhalb des Projekts, die zwischen zwei und vier Wochen dauern und in Zeit und Budget festgelegt sind. Jede Iteration endet damit, dass das Projektteam den Beteiligten die Ergebnisse und Fortschritte präsentiert. Bei APM geht es also um Feedback und Veränderungen in kurzen Iterationen, die entwickelt werden, um Veränderungen anzunehmen, anstatt sie abzulehnen (Williams & Cockburn, 2003).Selbstorganisierende TeamsSowohl Chow & Cao (2008) als auch Highsmith & Fowler (2001) beschreiben selbstorganisierende Teams als Einzelpersonen, die ihre eigene Arbeitslast verwalten, ihre Aufgaben je nach Bedarf und bester Eignung aufteilen und an der Entscheidungsfindung im Team teilnehmen. Nach Augustine et al. (2005) soll die Führung in selbstorganisierenden Teams leichtfüßig und anpassungsfähig sein. Die Verantwortung des Leiters besteht eher darin, die Richtung vorzugeben, die Mitarbeiter zu koordinieren, Ressourcen zu beschaffen und das Team zu motivieren, als endgültige Entscheidungen zu treffen (Anderson et al. 2003, Chau & Maurer 2004, Takeuchi & Nonaka 2005). 8Beteiligung von Kunden und StakeholdernNach Misra, Kumar & Kumar (2009) besteht die Idee der Agilität darin, Software effizient zu entwickeln, um die Kunden zufrieden zu stellen. Daher basiert ein zentraler Teil des APM auf der Integration und Einbeziehung von Kunden in die Prozesse. Dies kann auf drei Faktoren zurückgeführt werden: Kundenzufriedenheit, Kundenzusammenarbeit und Kundenengagement (ebd.). Mit dem APM-Setup können Stakeholder aktiv an Besprechungen, Planungssitzungen und Überprüfungen teilnehmen und sehen, was nach den Wiederholungen geliefert wurde.Kontinuierliche Verbesserung und LieferungDie kontinuierliche Lieferung innerhalb der Softwareentwicklung basiert auf der Idee, die Software ständig in einem releasefähigen Zustand zu halten (Fowler, 2013; Farley & Humble, 2010). Auf einer allgemeineren Ebene ist kontinuierliches Experimentieren jedoch die Idee, ein empirisches Verständnis des Kundenwerts zu erlangen, was ein Ansatz ist, bei dem potenziell wertvolle Funktionen an Kunden geliefert werden (Dingsøyr & Lassenius, 2016).2.2.2Neue Methoden Neue RollenWie bereits erwähnt, sind selbstorganisierende Teams, die Aufgaben teilen und an der Entscheidungsfindung beteiligt sind, charakteristisch für APM (Chow & Cao, 2008). Daher wird die Teamzusammensetzung zu einem zentralen Punkt bei der Verwaltung von Projekten. Teams in Scrum bestehen in der Regel aus einem Scrum Master, einem Product Owner und Teammitgliedern (Sutherland & Schwaber, 2013). Der ScrumMaster agiert als "moderner" Projektmanager in dem Sinne, dass er dafür verantwortlich ist, dass das Projekt Fortschritte macht und die anstehenden Aufgaben effektiv erledigt werden (Denning, 2015). Im Wesentlichen fungiert der Scrum Master als Moderator und Prozesscoach für das Team. Darüber hinaus fungiert der Scrum Master als direkter Ansprechpartner für andere Teams und Organisationseinheiten und beseitigt Hindernisse, die von der Organisation geschaffen wurden, sowie Hindernisse, die durch Abhängigkeiten zwischen den Teams entstehen. Eine weitere Rolle innerhalb von Scrum ist der Product Owner, der als direkter Kontakt zu den Stakeholdern fungiert und sich um Aufgaben kümmert, die mit der geschäftlichen Seite des Projekts zusammenhängen, wie Finanzierung, Feedback und Anforderungen (ebd.). Der Product Owner vertritt vor allem die Interessen der Stakeholder und kümmert sich um die Erwartungen der Stakeholder, die Priorisierung der Projektanforderungen, die allgemeine Produktvision und die Definition der Produktmerkmale (Hoda, Nobel & Marshall, 2010).Product Owner sollen verstehen und den Stakeholdern erklären, wie der Fortschritt ihres Projekts einen zusätzlichen Geschäftswert für die Organisation schafft. 9Stakeholder einen Mehrwert sehen. Im Wesentlichen fungiert der Product Owner als Brücke zwischen den beiden Seiten des Projekts: Das Team setzt sich aus Personen mit funktionsübergreifenden Fähigkeiten zusammen. Die funktionsübergreifenden Fähigkeiten sollen Autonomie ermöglichen und es wird erwartet, dass sie sich auf die Lieferung konzentrieren und selbst organisieren (Denning, 2015). (Übersicht über Scrum-Teams siehe Anhang)2.3 Merkmale von APM und TPMNachfolgend finden Sie eine Zusammenfassung (Tabelle 2) der Merkmale, die TPM und APM auf der Grundlage der bisherigen Literatur definieren:Tabelle 2.2.4Warum ist APM die Alternative?Wenn man weiß, was APM und TPM sind, kann man sich überlegen, warum IT-Abteilungen und Unternehmen gleichermaßen auf APM umsteigen. TPM und APM haben beide ihre Vor- und Nachteile. TPM zielt darauf ab, robuste Techniken und Best-Practice-Vorschläge zu gewährleisten, die sich leicht auf die meisten Projekte anwenden lassen. Während dies als Vorteil von TPM angesehen wird, halten Befürworter von APM dies für einen Nachteil. So argumentiert Wysocki (2007), dass es keine Einheitsgröße für alle gibt und dass das, was für einige Organisationen funktioniert, nicht unbedingt für alle gilt. Weiter führt er aus, dass Projekte, genau wie Geschäftsumgebungen, zunehmend komplexer werden, da die Anzahl der Aufgaben und Zusammenhänge zunimmt. Da TPM hauptsächlich auf hierarchischen und linearen Beziehungen zwischen Aufgaben aufbaut (Denning, 2015), kann es nicht die gesamte Komplexität und Dynamik heutiger Projekte angemessen widerspiegeln. Ein weiterer Nachteil ist, dass TPM davon ausgeht, dass Projekte von der Umwelt isoliert sind, obwohl Veränderungen in jeglicher Form die Realität heutiger Geschäftsumgebungen und somit auch die Realität von Projekten sind (Špundak, 2014). Die ursprünglichen Pläne MerkmaleAPMTPMStandardisierungNiedrigHochStrukturNicht-hierarchischHierarchischAnpassungsfähigkeitHochNiedrigDokumentationNiedrigHochVorhersagbarkeitNiedrigHochPlanungKontinuierlichVordefinierterProzessIterativNicht-iterativFührungskulturSelbstorganisierte TeamsBefehlsgesteuerte TeamsEinbindung der StakeholderKontinuierlich Anfänglich 10sind aufgrund der Unvorhersehbarkeit und der dynamischen Veränderungen des Geschäftsumfelds oder des Projekts zwangsläufig zu einem bestimmten Zeitpunkt zu ändern (Denning, 2015; Highsmith, 2004; Špundak, 2014; Wysocki, 2007; Conforto et al., 2014). Darüber hinaus ist es in der Anfangsphase der Projektplanung nur selten möglich, einen vollständigen Projektplan zu erstellen, was zum Teil auf die Schwierigkeiten bei der Definition künftiger Aufgaben und Ziele zurückzuführen ist (Špundak, 2014; Denning, 2015). Gegner des APM geben an, dass der Mangel an Struktur und klar definierten Plänen im APM die Ursache für Probleme mit der Effektivität sein kann. Špundak (2014) kommt zu dem Schluss, dass beide Methoden nützlich und effektiv sind, wenn sie richtig eingesetzt werden, und dass die Wahl der Methode auf dem umgebenden Geschäftsumfeld und der aktuellen Denkweise oder Ausrichtung der Mitarbeiter basieren sollte.In einer von Serrador & Pinto (2015) durchgeführten Studie testen die Autoren die Auswirkungen von APM in Organisationen auf zwei Dimensionen des Projekterfolgs, nämlich Effizienz und Gesamtzufriedenheit der Stakeholder, im Vergleich zu den Unternehmenszielen. Darüber hinaus wird die Studie in mehreren Branchen durchgeführt, um zu ermitteln, inwieweit APM mit dem Projekterfolg in Verbindung gebracht werden kann, wie es sich in verschiedenen Projektumgebungen bewährt und welche potenziellen Einflussgrößen diese Beziehung beeinflussen. Die Ergebnisse der Studie zeigen, dass APM tatsächlich mit dem Gesamterfolg von Projekten korreliert. Die Ergebnisse weisen nicht nur auf eine erhöhte Gesamterfolgsrate für die Organisationen hin, die APM anwenden. Die Fähigkeit, schnell auf sich ändernde Geschäftsanforderungen, Technologien und Marktbedingungen zu reagieren, sind Faktoren, die die zunehmende Beliebtheit von APM erklären (Augustine, 2005; Stavrou, 2014). Die Selbstorganisation von APM-Teams ist ein Merkmal, das Schnelligkeit ermöglicht und auch die Projektqualität erhöht (Chow & Cao, 2008). Selbstorganisierte Teams weisen ein höheres Maß an Autonomie auf, was die Zusammenarbeit im Team im Vergleich zu TPM verbessert (Hoda & Murugesan, 2016). Die lokale Kontrolle, die durch die Selbstorganisation gegeben ist, erleichtert nachweislich auch die Innovation (Lyytinen & Rose, 2006). Darüber hinaus ermöglicht die Autonomie die Dezentralisierung und Neuausrichtung der Entscheidungsfindung, wodurch die Menschen, die mit den alltäglichen Problemen konfrontiert sind und diese bearbeiten, gestärkt werden (Fowler & Highsmith, 2001; Kelley, 2008; Fowler, 2013; Farley & Humble, 2010). Dezentralisierung erhöht die Geschwindigkeit und Wirksamkeit der Problemlösung und Entscheidungsfindung (Larman 2004, Tata & Prasad 2004; Lee & Xia, 2005; Farley & Humble, 2010). Darüber hinaus schlagen Cockburn (2007) und MacCormacket al. (2001) vor, dass funktionsübergreifende Teams ihre Effektivität erhöhen, indem sie die Fähigkeiten der anderen ergänzen, um Veränderungen in der Umgebung zu erkennen und darauf zu reagieren. Die Anzahl der sich ändernden Benutzeranforderungen nimmt jedes Jahr zu, weshalb Unternehmen ein tieferes Kundenverständnis benötigen (Lee & Xia, 2010). 11 des APM ermöglicht es Unternehmen, ihren Kundenwert zu steigern. Durch die Verwendung von kurzen zeitbasierten Iterationen können Unternehmen effektiv frühes Nutzerfeedback erhalten. Die frühzeitige Einbindung von Kunden in Projekte und die Möglichkeit, Kundendaten frühzeitig zu nutzen, ermöglicht es Unternehmen, die Kundenbeziehungen zu verbessern, was zu einer höheren Kundenzufriedenheit führt (Dingsøyr & Lassenius, 2016; Misra, Kumar & Kumar, 2009). Mann & Maurer (2005, S. 9) bestätigen dies und geben an, dass die Kunden das Gefühl hatten, dass sie durch tägliche Besprechungen über das Projekt auf dem Laufenden gehalten wurden und dass "Planungsbesprechungen hilfreich waren und die Verwirrung darüber, was entwickelt werden sollte, verringert haben". Die Kunden fühlten sich zufriedener, da sie stärker einbezogen wurden. Außerdem wurde die liefernde Einheit als engagierter empfunden, da sie aktiv nach Feedback suchte (ibid.). Die stärkere Einbindung der Stakeholder hat zwar eine Reihe von positiven Aspekten, doch wird durch die Einbeziehung von Kunden und anderen Stakeholdern der Entscheidungsprozess komplizierter, da mehr Personen Einfluss auf die getroffenen Entscheidungen nehmen können. Auch wenn es Elemente erhöhter Komplexität gibt, ist die Einbeziehung der Stakeholder von zentraler Bedeutung für die Festlegung von Zielen und die Erzielung von Fortschritten. APM ermöglicht es den Stakeholdern, Einfluss darauf zu nehmen, was in der nächsten Iteration zu tun ist und welche Prioritäten gesetzt werden müssen, was die allgemeine Zufriedenheit erhöht (Serrador & Pinto, 2015). 2.5Essentials for Embrace of APMDieser Abschnitt soll auf der Grundlage früherer Erkenntnisse einen kurzen Überblick darüber geben, wann Organisationen über die Wahl von APM als Methode nachdenken sollten - Voraussetzungen, organisatorische Merkmale, Befähiger, Praktiken usw.Der Einsatz von APM ist für Teams von Vorteil, die innovativ sind und mit häufig wechselnden Stakeholder-Anforderungen umgehen müssen (Highsmith, 2004; Conforto et al., 2014; Serrador & Pinto, 2015). Ein weiteres Kriterium für die Entscheidung, ob APM die richtige Methode ist, ist die Teamgröße. Die empfohlene Anzahl der Teammitglieder beträgt acht. Neben der Teamgröße gibt es zwei weitere Hauptkriterien für die Entscheidung, ob APM geeignet ist: Praxis und Befähiger. Conforto et al. (2014) gehen speziell auf sechs APM-Praktiken ein, die im Folgenden aufgeführt sind:- Verwendung des Produktvisionskonzepts.- Verwendung einfacher Kommunikationswerkzeuge und -prozesse für die Projektplanung.- Verwendung iterativer Planung 12-Entwicklung von Aktivitäten unter Verwendung selbstverwalteter und selbstgesteuerter Teams im Projektplan-Verwendung selbstverwalteter und selbstgesteuerter Teams bei der Projektplanüberwachung und -aktualisierung-Häufige Anwendung von Projektplanüberwachungs- und -aktualisierungsprozessenEnablers beziehen sich auf Unterkriterien, die das Ergebnis von APM beeinflussen. Conforto et al. (2014) listen 41 Befähiger für APM auf. Die Befähiger werden nach ihren Erkenntnissen auf die 10 häufigsten und einflussreichsten heruntergefiltert. Diese sind im Folgenden aufgeführt und werden im folgenden Kapitel (2.5) weiter erörtert: - Einbindung von Lieferanten/Partnern - Art der Organisationsstruktur - Erfahrung der Projektteammitglieder - Größe des Projektteams - Engagement des Projektteams - Einbindung von Kunden/Stakeholdern in die Projektplanung - Multidisziplinäre Teams - Erfahrung des Projektleiters - Standort des Projektteams - Formalisierung des Produktentwicklungsprozesses (Der Zweck dieser Arbeit ist es, die Herausforderungen im Zusammenhang mit dem Übergang von TPM zu APM zu untersuchen. Daher wird die Formalisierung des Produktentwicklungsprozesses nicht behandelt, da sie sich auf die Produktentwicklung konzentriert. Außerdem sind Zulieferer und Partner Stakeholder, so dass die Beteiligung von Zulieferern/Partnern als Stakeholder-Beteiligung bezeichnet und behandelt wird.) Bei der Umstellung von Managementmethoden in Organisationen ist die Unterstützung durch das Management von entscheidender Bedeutung, da das Management die Kontrolle über die Ressourcen, die Festlegung der Ziele und die Entscheidung über die Prioritäten für die Weiterentwicklung hat. Darüber hinaus ist eine geeignete Organisationskultur, die auf die neuen Managementmethoden abgestimmt ist, erforderlich, um einen erfolgreichen Wandel zu ermöglichen (Näslund, 2013). 132.6 Zu erwartende Herausforderungen bei der Umstellung auf APMBei der Diskussion darüber, was Erfolg im Rahmen von APM eigentlich bedeutet, gibt es unterschiedliche Ansichten (Pinto & Slevin, 1988). Atkinson (1999) und Kerzner (2003) stellen fest, dass einige Forscher meinen, dass Erfolg durch die Qualität des Endprodukts und den erfolgreichen Umgang mit den so genannten dreifachen Zwängen von Zeit, Umfang und Budgetzielen (d.h. dem Eisernen Dreieck) definiert wird. Andere meinen, dass der Erfolg eher durch ein breiteres Spektrum von Kriterien definiert werden sollte, wie z. B. die Auswirkungen auf die jeweilige Organisation, als durch die erfolgreiche Überwindung einer Reihe von Einschränkungen (Carvalho et al., 2015; Jugdev & Müller, 2005). Jugdev & Müller (2005) stellen nach einer Überprüfung der vorhandenen Literatur über Projekterfolg und -herausforderungen fest, dass der traditionelle Begriff des Erfolgs im APM (Überwindung von Beschränkungen) durch Literatur ersetzt wird, die einen ganzheitlicheren Ansatz zur Erfolgsmessung verfolgt. Das bedeutet, dass mehr Parameter als Erfolgsfaktoren berücksichtigt werden, was ein breiteres Spektrum an potenziellen Herausforderungen mit sich bringt, da der Fokus breiter gefasst ist. Thomas et al. (2008) erwähnen, dass die Messung des Projekterfolgs nicht so einfach ist, wie die bisherige Literatur vermuten lässt. Statt strikt nach Erfolgsfaktoren zu suchen, sollte die Aufmerksamkeit auf die tatsächlichen Herausforderungen gerichtet werden, die den Erfolg verhindern. So untersuchen Thomas et al. (ebd.) eine Reihe von Projekten, von denen einige trotz Einhaltung der ursprünglichen Vorgaben in Bezug auf Budget, Zeit und Umfang mit einem Kunden enden, der mit den Ergebnissen unzufrieden ist. Während viele frühere Forschungsarbeiten die Vorteile von APM belegen können, finden Hoda & Murugesan (2016) 8 Hauptherausforderungen bei APM, die mit 4 verschiedenen Ebenen innerhalb der Organisation verbunden sind: Projekt-, Team-, Einzel- und Aufgabenebene. Die Projektebene umfasst Aktivitäten, an denen das selbstorganisierende Team, der Scrum Master (oder Projektmanager) und der Product Owner (oder Kundenvertreter) beteiligt sind. Die Teamebene umfasst Aktivitäten, an denen das sich selbst organisierende Team und der Scrum Master beteiligt sind, die individuelle Ebene umfasst Aktivitäten wie die Selbstzuweisung von Aufgaben, an denen einzelne Teammitglieder beteiligt sind. Die Aufgabenebene umfasst Aktivitäten, die sich auf technische Aufgaben beziehen. Herausforderungen entstehen nicht nur auf verschiedenen Ebenen, Hoda & Murugesan (2016) kommen auch zu dem Schluss, dass Herausforderungen auf einer Ebene mit Herausforderungen auf anderen Ebenen zusammenhängen und diese beeinflussen. Moe, Dingsøyr & Dybå (2009) hingegen kategorisieren Herausforderungen auf Team- und Organisationsebene mit dem Argument, dass sich Herausforderungen auf Organisationsebene auf die Teamleistung auswirken. Da die in der Literatur vorgestellten Herausforderungen gut mit der von Hoda & Murugesan (2016) und Moe, Dingsøyr & Dybå (2009) vorgenommenen Unterteilung übereinstimmen, wird ein kombiniertes Modell angepasst, das als analytischer Rahmen dient und Herausforderungen auf organisatorischer Ebene, Teamebene und individueller Ebene enthält. 14 Herausforderungen auf der OrganisationsebeneDie APM-Implementierung ist eine bekannte Herausforderung auf der Organisationsebene, genauer gesagt wirken organisatorische Zwänge als das Haupthindernis für eine erfolgreiche Arbeit mit APM (Boehm & Turner, 2005). Unternehmen neigen dazu, den Bereich des APM ohne das richtige Maß an Vorbereitung und Engagement zu betreten. Diese Organisationen laufen Gefahr, auf organisatorische Hindernisse zu stoßen, die mit den Veränderungen in den Entwicklungsprozessen, den Geschäftsprozessen und dem Personalmanagement zusammenhängen (Boehm & Turner, ebd.). Daher können die Hindernisse vermieden werden, indem ein Verständnis für die grundlegenden Unterschiede zwischen TPM und APM aufgebaut wird. Außerdem kann die Organisation durch sorgfältige Vorbereitung, Arbeit und Geduld die Wahrscheinlichkeit erhöhen, die anfänglichen Herausforderungen zu überwinden (ebd.). Die gemeinsame Entscheidungsfindung ist eine Folge des APM, bei dem die Entscheidungsfindung von der oberen Führungsebene auf die Arbeitsteams verlagert wird (Denning, 2015). Das Konzept der selbstorganisierenden Teams gibt den Teams die Befugnis, Entscheidungen zu treffen, wodurch das Management von den auf Teamebene getroffenen Entscheidungen abgekoppelt wird. Diese Abkopplung kann zu Schwierigkeiten bei der Ausrichtung der Strategie führen, da die Interessen des Teams nicht immer mit den Interessen des Managements an der Gesamtstrategie des Unternehmens übereinstimmen (Moe, Aurum, & Dybå, 2011; Denning, 2015). Darüber hinaus erwähnen Moe, Dingsøyr & Dybå (2009) Probleme mit der organisatorischen Kontrolle, wie z. B. die detaillierte Berichterstattung, die vom Team als unnötiger Mechanismus angesehen wurde, um die Kontrolle zu behalten.Nach Young & Jordan (2008) ist die Unterstützung durch das Management der wichtigste Erfolgsfaktor für den Projekterfolg. Daher ist die Unterstützung durch die obere Führungsebene eine Herausforderung, die bewältigt werden muss. Der Faktor Unterstützung ist wichtig, da die obere Führungsebene häufig für die Genehmigung von Finanzmitteln und Entscheidungen über organisatorische Veränderungen und Umstrukturierungen (Stettina & Hörz, 2015; Näslund, 2013) sowie für die Kommunikation der Botschaft innerhalb der Organisation verantwortlich ist. Ohne die Unterstützung des Managements werden Initiativen schnell eingestellt oder scheitern, unabhängig von der Art der Initiative (Stettina & Hörz, 2015; Young & Jordan, 2008). Hoda & Murugesan (2008) erörtern auch das Sponsoring durch die Führungsebene (d. h. die Unterstützung durch die oberste Führungsebene) als eine Herausforderung, die bewältigt werden muss, um selbstorganisierende Teams zu erreichen.Herausforderungen auf TeamebeneBezugnehmend auf eines der vier Grundprinzipien von APM - die Bedeutung der Wertschätzung von Personen und Interaktionen gegenüber Prozessen und Tools (Fowler & Highsmith 2001, S. 2). APM basiert auf Kollektivität und selbstorganisierenden Teams, die zusammenarbeiten können. Daher ist die Schaffung einer 15 einheitliche Vision des Projekts innerhalb der Projektteams eine Herausforderung bei der Anwendung von APM (Fernandes et al., 2015). Eine weitere Herausforderung auf Teamebene, die sich bei der Selbstorganisation ergibt, ist die Ressourcenzuteilung: Wenn die Entscheidungsbefugnis auf das Team übertragen wird, ändert sich das Finanzierungsverfahren. Dies erfordert, dass die Mitarbeiter auf Teamebene oder der Produkteigentümer sich um die Finanzierung bemühen, was sonst von der übergeordneten Ebene erledigt wird (Moe, Aurum, & Dybå, 2011; Denning, 2015).Moe, Dingsøyr & Dybå (2009) stellen fest, dass mangelndes individuelles Engagement eine Herausforderung auf Teamebene für Mitglieder in selbstorganisierten Teams ist. In Kombination damit erwähnen sie auch die Verwirrung um die individuelle Führung als eine Herausforderung für selbstorganisierende Teams. In ähnlicher Weise erwähnen Conforto et al. (2014, S. 29) das Engagement des Teams und fügen die Co-Location hinzu: "Die größte Herausforderung ist die Co-Location und das Engagement des Teams." Im Rahmen von APM ist es von entscheidender Bedeutung, dass die Teams an einem Ort zusammenarbeiten, denn die ganze Idee von APM besteht darin, dass die Mitglieder in der Lage sein sollten, schnell zu reagieren, Feedback einzuholen, Änderungen vorzunehmen und sich selbst zu organisieren. Wenn Teams nicht an einem Ort zusammenarbeiten, gehen viele dieser Aspekte verloren; wenn Teams beispielsweise nicht an einem Ort zusammenarbeiten und nicht von Angesicht zu Angesicht miteinander sprechen können, nimmt die Agilität und Selbstorganisation des Teams ab (Conforto et al., 2014). APM ermöglicht eine stärkere Einbindung der Kunden, doch obwohl dies nachweislich Vorteile für die Unternehmen mit sich bringt, haben die Forscher auch Herausforderungen im Zusammenhang mit der Einbindung der Kunden identifiziert: Die Entfernung zwischen dem Projektteam und seinen Kunden ist eine Herausforderung im Zusammenhang mit der Kundeneinbindung. Eine weitere Herausforderung bei dem Versuch, die Kunden einzubeziehen, besteht darin, dass die Kunden APM nicht verstehen, da es sich nicht um eine allgemein verständliche und akzeptierte Methode handelt, was die Kunden dazu veranlasst, Skepsis zu zeigen (Hoda, Noble & Marshall, 2010). Eine mangelnde Einbeziehung der Kunden kann Folgen haben, wie z. B. Überforderungsdruck, Probleme bei der Erfassung und Klärung von Anforderungen, Probleme bei der Priorisierung von Anforderungen, Probleme bei der Sicherstellung von Feedback, Produktivitätsverlust und in extremen Fällen Geschäftsverlust (ebd.). Korkala, Abrahamsson & Kyllönen (2010) betonen ebenfalls, wie wichtig es ist, dass die Kunden vor Ort sind, um dem Team klare Anforderungen und konstruktives Feedback zu geben. Darüber hinaus stellten sie fest, dass die Qualität des Endprodukts sinkt, wenn die Kommunikation von Angesicht zu Angesicht nicht gegeben ist. Außerdem zeigte die Studie, dass die Qualität des Endprodukts abnimmt, wenn die persönliche Kommunikation mit dem Kunden abnimmt. 16Herausforderungen auf individueller EbeneDie Selbstzuweisung von Aufgaben kann für Einzelpersonen zu einer Herausforderung werden, wenn sie als selbstorganisierende Teams im APM arbeiten. Moe, Aurum & Dybå (2011) fanden heraus, dass Teammitglieder dazu neigen, Aufgaben zu vermeiden, die als weniger glamourös angesehen werden, wie Wartungs- und Verwaltungsaufgaben. Die Mitglieder von selbstorganisierenden Teams sind jedoch dafür verantwortlich, freiwillig die Aufgaben zu übernehmen, die zur Erreichung des Ziels erforderlich sind. Im Gegensatz zu diesen Erkenntnissen über Aufgaben stellten Vidgen & Wang (2009) fest, dass Teammitglieder immer wieder die einfachsten Aufgaben wählen. In beiden Fällen zeigen die Ergebnisse Herausforderungen in Bezug auf die Selbstzuweisung von Aufgaben, wenn auch in unterschiedliche Richtungen.Moe, Dingsøyr & Dybå (2009) stellen fest, dass das Versäumnis, die APM-Arbeitsmethoden zu erlernen, als Herausforderung auf dem Weg zu einem autonomen, selbstorganisierten Team angesehen werden kann. Sie argumentieren, dass Teams ihre Arbeitsnormen und -regeln ändern müssen, um sich selbst zu managen. Darüber hinaus stellen sie fest, dass bei der Anwendung von APM und dem Versuch, selbstorganisiert zu werden, Verwirrung über die individuelle Führung entsteht. Die Teammitglieder sind sich nicht unbedingt darüber im Klaren, dass sie für ihr eigenes Handeln verantwortlich sind und dafür sorgen müssen, dass die Aufgaben wie erwartet erledigt werden (ebd.). 172.7Analytischer RahmenDie vorhandene Literatur und Forschung zum Thema APM und insbesondere zu den Herausforderungen gibt einen Überblick darüber, welche Herausforderungen derzeit in diesem Teilbereich der APM-Forschung entdeckt wurden. Daher kann die vorhandene Literatur als Grundlage für einen analytischen Rahmen dienen. Der Rahmen soll unterscheiden, welche Herausforderungen explizit mit den APM-Methoden verbunden sind und welche Herausforderungen mit dem Übergang zu APM in Verbindung gebracht werden können. In Anlehnung an das bestehende Thema ist der Rahmen in drei Hauptkategorien unterteilt: Organisationsebene, Teamebene und individuelle Ebene. Diese Unterteilung soll die Suche nach Herausforderungen erleichtern und spezifizieren, wo diese zu erwarten sind. Außerdem folgt auf jede Kategorie eine Liste von Unterkategorien (in den weißen Kästen), um zu verdeutlichen, wonach die Autoren bei der Erhebung und Analyse empirischer Daten in der Studie suchen. Die Pfeile, die im Rahmen nach unten zeigen, veranschaulichen, dass die Herausforderungen von der Organisationsebene auf die Team- und Individualebene übergehen können. Die gebogenen Pfeile deuten auf das Gegenteil hin: Herausforderungen auf individueller Ebene haben das Potenzial, auf die Organisationsebene überzugreifen und sich letztlich auf die gesamte Organisation auszuwirken. Read Less