Reifegradmodell "Agile Ready" für das Projektmanagement

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung und Problemstellung
1.1 Hintergrund der Arbeit
1.2 Problemstellung und Zielsetzung
1.3 Methodisches Vorgehen

2 Theoretische Grundlagen
2.1 Projektmanagement
2.1.1 Vorgehen und Aufgaben im Projektmanagement
2.1.2 Erfolgsfaktoren im Projektmanagement
2.2 Unternehmen als Umfeld von Projekten
2.2.1 Mögliche Formen der Integration
2.2.2 UnternehmenskulturalsErfolgsfaktor
2.3 Agiles Management
2.3.1 Agiles Manifest und seine Prinzipien
2.3.2 Erfolgsfaktoren im Agilen Management

3 Zwischenfazit

4 Entwicklung des Reifegradmodells Agile Ready“
4.1 Prozessfelder zur Beurteilung der „Agile-Fähigkeit“
4.2 Entwurf eines Assessment-Fragebogens
4.2.1 ErfassungstatistischerDaten
4.2.2 Erhebung kontextbezogener Daten
4.2.3 Messung von ”AgileReady“
4.2.4 Entwicklung einer passenden Metrik
4.3 Plausibilisierung des Fragebogens
4.4 Uä berfuährung in die Praxis

5 Zusammenfassung und Ausblick
5.1 Fazit der Untersuchung
5.2 Kritische Wuärdigung
5.3 Zukuänftige Forschungsansaätze

Literaturverzeichnis

Sachverzeichnis

Abkürzungsverzeichnis

Ergänzende Abbildungen

Ergänzende Tabellen

Frägebogen

Variablenübersicht

Vorwort

Die schönste Blume wachst nicht, wenn Du den Keim in die Wüste schmeißt.

— unbekannt

Seit dem erfolgreichen Abschluss meines ersten Studiums des Wirtschaftsin­genieurwesens vor neun Jahren habe ich oft darüber nachgedacht, mein Wissen in Richtung Informatik zu verbreitern. Durch die beruflichen Stationen im Pro­jektmanagement bei SCHOTT, der EnBW Energie Baden-Württemberg, Leadec (vormals Voith Industrial Services) und heute bei TRUMPF bin ich in verschie­denen Fach- und Führungspositionen immer wieder mit IT-Themen in Berührung gekommen. Irgendwann war der lose Gedanke dann zum konkreten Vorhaben ge­reift, so dass ich im September 2016 das Fernstudium Informatik an der Hochschule Trier aufnahm.

Gleichzeitig habe ich vor einigen Jahren begonnen, mich mit dem Thema Agi- litat noch intensiver zu beschaftigen und dabei ist naturlich aufgefallen, dass heut­zutage jeder agil sein mochte, koste es, was es wolle. Meetings werden umbenannt und Projektleiter heißen plötzlich Produkt Owner oder Scrum Master. Dabei sind viele Organisationen uberhaupt nicht in der Lage, Projekte auf diese Weise abzu­bilden. Sie beriicksichtigen nicht, dass bestimmte Rahmenbedingungen im Umfeld gegeben sein mussen, um einerseits die agile Durchführung und andererseits den Projekterfolg uberhaupt zu ermöglichen.

Ich bin der Hochschule Trier sehr dankbar, dass ich mich im Rahmen der vor­liegenden Projektarbeit als Teil des Fernstudiums mit diesem Thema beschaöftigen durfte und moöchte die Gelegenheit nutzen, mich bei meinem Betreuer Prof. Dr. Walter Jakoby, bei unserer Studiengangskoordinatorin Fernstudium Informatik Gaby Elenz sowie bei unserem Vorsitzenden des Pruöfungsausschusses Informatik Prof. Dr. rer. nat. Andreas Lux dafuör zu bedanken. Natuörlich danke ich auch den mir nahestehenden Menschen, die mich jederzeit unterstuötzen. Denn die Doppel­belastung Berufstaötigkeit und Fernstudium bedeutet leider auch manchmal, dass ich nicht immer so fuör sie da sein kann, wie ich es gerne moöchte.

Juliane Patricia Pilster

Stuttgart, April 2018

Kurzfassung

Der Gegenstand der vorliegenden Arbeit ist die Entwicklung eines Reifegradmo­dells zur Einordnung von Unternehmen im Kontext des agilen Projektmanage­ments. Dafür wurden zunächst die Erfolgsfaktoren von Projektmanagement und von agilem Management erarbeitet und anschließend miteinander verknupft, um eine Gliederung fur das Reifegradmodell zu erhalten. Organisationale und kultu­relle Aspekte wurden ebenfalls in die Betrachtung einbezogen.

Die Operationalisierung der daraus entstandenen Kategorien Auftragstrans­parenz, Adaptionsfahigkeit, Feedbackzugang, Befugnisauspragung, Stabilitatsaus- pragung, Ergebnisbewertung, Zusammensetzung, Freiheitsgrade und Reflektions- fahigkeit erfolgte mit Hilfe von Aussagen, die in einen Fragebogen uberfuhrt wur­den. Die Durchfuhrung einer Online-Umfrage diente dann der Plausibilisierung der Kategorien.

Somit konnte das Reifegradmodell Agile Ready“ dargestellt und beschrieben sowie praktische Hinweise zur Verwendung gegeben werden. Die Arbeit schließt ab mit einer Zusammenfassung der wesentlichen Aspekte, einer kritischen Wurdigung und Vorschlagen fur zukunftige Untersuchungen.

The subject of the following paper is the development of a maturity model to classify enterprises in the context of agile project management. Therefore, success factors of both, project and agile management, had been identified and after that compiled in order to derive the categories of the maturity model. Organizational and cultural aspects were included into the study as well.

Then, it was necessary to break down the 9 categories derived from the findings job clarity, adaption skills, feedback access, degree of competencies, degree of sta­bility, result assessment, composition, degree of freedom, and the ability to reflect, into main statements that describe a particular category. An online survey served as a basis to check reasonableness.

Finally, the maturity model Agile Ready“ was illustrated, described as well as provided with some practical hints for its usage. The paper closes with a summary of the main aspects, a critical appraisal, and some ideas for further study.

Abbildungsverzeichnis

1.1 Auswirkungen eines agilen Prozesses auf den Proj ekterfolg

1.2 Niveaustufen im Zusammenhang mit Agile Fluency

2.1 Magisches Dreieck im Projektmanagement

2.2 Handlungsfelder im Proj ektmanagement

2.3 DimensionenimProjektmanagement

2.4 Einflüsse im Umfeld eines Projekts

2.5 Notwendige Inputfaktoren zur Problemlüsung

2.6 DimensionenimProjektmanagement

2.7 EbenenvonErfolgsfaktorenimProjektmanagement

2.8 KriterienzurAuswahlderProjektorganisation

2.9 MagischeTriologieausStrategie,StrukturundKultur

2.10 Moving Target als Grundannahme fuür Agilitaüt

2.11 Feedbackschleifen in ergebnisoffenen Veraünderungen

2.12 Erfolgsfaktoren des agilen Managements nach Sichten

4.1 Zusammenhang zwischen Stufen und Prozessfeldern

4.2 Prozessfelder des Reifegradmodells

4.3 Einteilung der Stichprobe nach Altersklassen

4.4 Einteilung der Stichprobe nach Unternehmensgroüße

4.5 Einteilung der Stichprobe nach Projektarten

4.6 Wortwolke aus Nennungen zurFrage AK01

4.7 Selbsteinschaützung der Teilnehmer zu Agilitaüt

4.8 Zusammenhang zwischen Zertifizierung und Selbsteinschüatzung . . . .

4.9 Zusammenhang zwischen Zertifizierung und Umfeldeinschüatzung . . .

4.10 Zusammenhang zwischen Unternehmensgroüße undUmfeld

4.11 Dimensionsauspraügungen nach Unternehmensgrüoße

4.12 Dimensionsauspraügungen nach Projektart

4.13 Aufbau des Reifegradmodells Agile Ready“

4.14 Standortbestimmungmit Hilfe des Agile-Ready-Modells

B.1 Reine Projektorganisation

B.2 Matrixprojektorganisation

B.3 Stabsprojektorganisation

B.4 Strukturierung der Arbeit

B.5 Einteilung der Stichprobe nach Geschlecht

B.6 Einteilung der Stichprobe nach Postleitzahlen

B.7 Einteilung der Stichprobe nach Abschluss

B.8 Einteilung der Stichprobe nach Art der Fuöhrungsverantwortung . . . .

B.9 Einteilung der Stichprobe nach Taötigkeitsfeld

B.10 Einteilung der Stichprobe hinsichtlich agilen Arbeitens

B.11 Angaben der Teilnehmer zu Ausbildung im Bereich Agilitaöt

B.12 Dimensionsauspraögungen nach Zertifizierung

Tabellenverzeichnis

2.1 Grundannahmen in klassischen und agilen Vorgehensmodellen

2.2 ErfolgsfaktorenimProjektmanagement

4.1 Verteilung der Begriffsnennungen (mit vs. ohne Zertifizierung)

C.1 Vor- und Nachteile verschiedenerProjektorganisationen

C.2 Begriffsnennungen sortiert nach Haäufigkeit

1. Einleitung und Problemstellung

1.1 Hintergrund der Arbeit

In den letzten Jahrzehnten haben sich in zahlreichen Unternehmen aller Branchen vermehrt Projektorganisationen etabliert. So ist zum Beispiel zu erwarten, dass im kommenden Jahr 2019 in Deutschland bereits fast die Haälfte der Arbeitszeit in Projektarbeit investiert werden wird. Verglichen mit dem Jahr 2009 entspricht dies einem Anstieg von uäber 40 Prozent innerhalb eines Jahrzehnts. [GPM15, S. 20-22] Bezogen auf die Projektarbeit selbst bedeutet dies eine Steigerung von uäber 60 Prozent [Hay15, S. 13]. Komplexitäat, Neuartigkeit und Umfang sowie die zeitli­che Begrenzung von Aufgabenstellungen werden als Gruände genannt, Themen im Rahmen von Projekten abzuwickeln. Die betrifft nicht nur Unternehmen, sondern ebenso oäffentliche Einrichtungen. Auch die strukturelle Anpassung von Organi­sationen an vorstehend genannte Herausforderungen erfolgt häaufiger als zuvor in Projektform. [Boh10, S. 17-18], [Ste14, S. 60]

Eine wesentliche Ursache fuär die zunehmende Beliebtheit von Projekten besteht neben verkuärzten Innovations- und Produktlebenszyklen [Wie08, S. 1] in individu­ellen Kundenbeduärfnissen, die speziell angepasste Produkte oder Dienstleistungen notwendig machen, die in ihrer Art nur einmalig oder in kleinen Mengen benoätigt werden. Zu ihrer Anfertigung bzw. Erbringung kann dann nicht oder nur bedingt auf bestehende Standards wie Methoden oder Prozessmodelle zuruäckgegriffen wer­den, wodurch andere Organisationsstrukturen erforderlich werden. Eine Projektor­ganisation kann in solchen Faällen flexibler als eine hierarchisch aufgebaute Struktur reagieren. [Boh10, S. 17-18], [KHL+06, S. 3], [Ste14, S. 60]

In der Studie Rethink! SPMS - Driving the Internet of Manufacturing Studie 2017“ gaben 233 Entscheider aus verschiedenen Branchen in der D/A/CH-Region sogar an, dass die Beherrschung der Komplexitäat in der eigenen Organisation die groäßte Huärde fuär die Umsetzung von Industrie 4.0 sei [SPM17]. Gleichzeitig werden komplexere Aufgabenstellungen als weiterer Grund fuär die steigende Anzahl von Projektorganisationen angesehen [Boh10, S. 17-18], [Ste14, S. 60]. Der Annahme folgend, dass Komplexitaät also auch zukuänftig ein Treiber fuär die Etablierung von Projektstrukturen sein wird, kann also auch uäber 2019 hinaus noch von einem weiteren Zuwachs ausgegangen werden und die Bewaältigung der Komplexitäat wird dabei eine zentrale Herausforderung sein.

1.2 Problemstellung und Zielsetzung

Bezugnehmend auf die zuvor beschriebenen Herausforderungen sollen im Folgen­den konkrete Problemstellung und Zielsetzung abgeleitet werden.

Komplexe Aufgabenstellungen zeichnen sich insbesondere durch Unvorhersag­barkeit zukunftiger Geschehnisse aus, d.h. die finale Losung ist möglicherweise unbekannt, zu verwendende Technologien und der Losungsweg ebenfalls. Unter Umstanden öndern sich sogar Anforderungen uber die Zeit. Weitere Aspekte sind die Dynamik innerhalb des Projektteams, die Moglichkeit zur Einbindung von Endnutzern und die Modularisierbarkeit des Endergebnisses. [Max13, S. 16], [RST02, S. 15], [Sch04, S. 23] Einige Leitplanken zur Annaherung an diese Komple- xitat im Rahmen einer Projektorganisation bietet unter anderem das Rahmenwerk „Scrum“¹ an, das empirische Prozesskontrolle ermöglicht. Diese steht im Gegensatz zu definierter Prozesskontrolle, die eine gleichbleibende Qualität des Ergebnisses auf der Basis eines sich wiederholenden Prozesses sicherstellt.[Sch04, S. 24]

Auf Grund zahlreicher Erfolgsgeschichten im Hinblick auf Effizienz, Time-to- Market, Kundenzufriedenheit oder Mitarbeitermotivation setzen immer mehr Un­ternehmen in Projekten auf so genannte agile Ansätze wie Scrum - allerdings nicht immer erfolgreich. [RST02, S. 14], [Hay15, S. 16] Laut der Studie „Von star­ren Prozessen zu agilen Projekten“ von Hays (2015, S. 15) scheitert fast jedes sechste Projekt. Daruber hinaus zeigt die jungste CHAOS-Studie² der Standish Group, dass zumindest agile Software-Projekte im Sinne des Budgets, des Zeitrah­mens und der inhaltlichen Anforderungen durchschnittlich zumindest erfolgreicher verlaufen als klassische (vgl. Abbildung 1.1). Dennoch sind es immer noch uber 50 Prozent der Projekte, die in Schwierigkeiten geraten (45%) oder sogar scheitern (6%). [Joh18, S. 9]

Eine Ursache fur das Scheitern von Projekten kann darin bestehen, dass die Fahigkeit eines Unternehmens, Projekte durchzufuhren, uberschatzt wird. Die Ent­scheidung allein, agile Praktiken im Projektmanagement einzusetzen, ist nicht aus­reichend fur die Steigerung der Erfolgsrate von Projekten. [BM13, S. 345] In ihrem Modell Agile Fluency™ beschreiben Larsen und Shore (2012) den Begriff Flu­ency³ als Föhigkeit, auch unter Druck agil arbeiten zu konnen und durch die routi­nierte Ausubung von Tatigkeiten erfolgreich zu sein. Naturlich steht dabei im Vor­dergrund die Leistung des Teams, die jedoch abgesehen von den Fahigkeiten der Teammitglieder insbesondere von außeren Gegebenheiten abhangt. Dazu zöhlen zum Beispiel struktuelle und kulturelle Rahmenbedingungen (vgl. Abschnitt 2.2). Die Autoren halten fest, dass in Bezug auf eine Organisation selbst nicht von Agi­le Fluency gesprochen werden kann, allerdings kann eine Organisation das notige Umfeld darstellen, das Agile Fluency ermöglicht und ohne das einzelne Teams nicht erfolgreich sein können. [LS12]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.1. Auswirkungen eines agilen Prozesses auf den Projekterfolg

Quelle: Johnson (2018, S. 8).

Im Rahmen der vorliegenden Arbeit soll der angesprochene Aspekt der Orga­nisation als so genannter Enabler“ fuür den Erfolg agiler Projekte herausgegriffen und untersucht werden. Die Erkenntnisse küonnen dann in ein Reifegradmodell uüberfuührt werden, da diese dazu geeignet sind, Verbesserungspotenziale auf der Ebene der Organisation zu behandeln [BM13, S. 346]. Analog zum Titel State of Readiness“ des Autors Paris Jr. (2017), in dem ein Modell zur Reifegradbe­stimmung von Unternehmen hinsichtlich Operational Excellence vorgestellt wird [Par17, S. 311], soll dazu ein Reifegradmodell in Bezug aufAgilitaüt entwickelt wer­den: Agile Ready“. Dazu sind die folgenden Forschungsfragen zu beantworten:

FF01 Welche Faktoren besitzen Relevanz fuür den Erfolg von Proj ekten?

FF02 Welche Besonderheiten weisen agile Projekte dabei auf?

FF03 Wie küonnen solche Faktoren bei Unternehmen gemessen werden?

1.3 Methodisches Vorgehen

Die Bearbeitung der zu Grunde liegenden Problemstellung erfolgt in drei Ab­schnitten: Zunüachst sollen im Kapitel 2 die theoretischen Grundlagen erlaüutert wer­den. Hierfuür ist die Beschreibung der wichtigsten Aspekte in Bezug auf Projektma­nagement, deren organisatorische Einbettung sowie agiles Management notwendig. Dabei wird insbesondere auf die relevanten Begrifflichkeiten und die Erfolgsfakto­ren der drei Themenbereiche eingegangen. In Kapitel 3 werden im Rahmen eines Zwischenfazits die Erkenntnisse aus der theoretischen Betrachtung resuümiert .

Anschließend befasst sich das Kapitel 4 mit der Messbarkeit der Agile-Faühigkeit“ einer Organisation. D afuür wird auf die im ersten Teil der Arbeit abgegrenzten Be­griffe Bezug genommen und geeignete Handlungsfelder als Basis fuür das Reifegrad­modell Agile Ready“ herausgearbeitet. Diese werden dann in einen Fragebogen überführt, mit weiteren statistischen und kontextbezogenen Fragen angereichert und es wird eine geeignete Metrik entwickelt, um den Fragebogen auswertbar zu machen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.2. Niveaustufen im Zusammenhang mit Agile Fluency Quelle: Larsen und Shore (2012).

Mit Hilfe einer Online-Umfrage soll der Fragebogen getestet ünd insbesondere die Plausibilität der Handlungsfelder überprüft werden. Die auf dieser Basis erho­benen Daten werden dazü aüsgewertet ünd die Ergebnisse dargestellt; aüßerdem werden die Auswertungen verschiedener Fragen ins Verhäaltnis gesetzt. Schließlich wird das Reifegradmodell Agile Ready“ dargestellt und mit Hilfe der Beschrei­bung von Reifegradkategorien operationalisiert.

Im abschließenden Kapitel 5 sollen die Erkenntnisse aus der Arbeit dargestellt, Schwachstellen benannt und Raum fuär zukuänftige Untersuchungen aufgezeigt wer­den.

2. Theoretische Grundlagen

Im folgenden Abschnitt 2.1 werden zunachst die relevanten Grundlagen zum The­ma Projektmanagement beschrieben, bevor anschließend die Einbettung in den unternehmerischen Kontext erfolgt (vgl. Abschnitt 2.2). Abschließend werden die wesentlichen Aspekte des agilen Managements beschrieben (vgl. 2.3). Ein Schwer­punkt des theoretischen Teils liegt auf den relevanten Zusammenhangen und den jeweiligen Erfolgsfaktoren.

Projekte dienen der systematischen Losung von Problemen [PR11, S. 20]. Eine detaillierte Klassifizierung von Projekten zum Beispiel nach Große, Inhalt oder anderen Kriterien¹ soll in der vorliegenden Arbeit aus Vereinfachungsgriinden nicht erfolgen. An dieser Stelle sei nur erwahnt, dass sich ein Projekt vor allem durch die nachfolgend genannten Charakteristika auszeichnet²:

- ist einmalig, nicht wiederkehrend
- hat eine festgelegte Dauer und ein klares Ziel
- zeichnet sich durch Komplexitat aus
- beschaftigt sich mit etwas Neuem
- umfasst verschiedene Disziplinen
- verfugt uber spezifische Ressourcen
- erhült eine Projektorganisation
- erfordert anderes Management als das Alltagsgeschaft
- enthült Risiken und Unsicherheiten
- besitzt eine Mindestanzahl von Teilnehmern

Wie in Abschnitt 1.1 bereits angesprochen wurde, ergibt sich aus immer kom­plexeren Aufgabenstellungen die Notwendigkeit einer systematischen Abwicklung. Dies geschieht insbesondere vor dem Hintergrund steigender Anforderungen an Projekte [WW06, S. 29] zur Entwicklung neuer Produkte und Dienstleistungen in Bezug auf Qualitat, Funktionen, Kosten und Termine: Projektmanagement (PM) bildet dafur einen passenden Rahmen [Jak15, S. 8].

2.1 Projektmanagement

Das wesentliche Ziel von PM besteht in der erfolgreichen Abwicklung eines Pro­jekts, wobei Erfolg auf einer uöbergeordneten Ebene durch das Magische Dreieck“ (vgl. Abbildung 2.1) beschrieben werden kann, das den Zusammenhang zwischen Inhalt, Zeit und Kosten eines Projekts darstellt³. Die Nichteinhaltung des magi­schen Dreiecks“ wirkt sich sowohl auf die projektfuöhrende Organisation als auch auf den Kunden aus; finanzielle Schwierigkeiten und Zeitdruck sind in der Regel die Folgen. [Tec15, S. 15]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1. Magisches Dreieck im Projektmanagement

Quelle: Eigene Darstellung nach Bohinc (2010, S. 19).

PM kommt dabei als Menge aller Planungs- und Steuerungsaktivitöaten sowie Steuerungsmethoden und Organisationsmodelle zum Einsatz [Jak15, S. 10] [KW10, S. 15-16]. Daraus ergeben sich folgende Detailziele des Projektmanagements:

- Durchführung von geeigneten Maßnahmen zur Initiierung, zum Start, zum Con­trolling, zur Koordination und zum Abschluss von Projekten
- Sicherstellung der Projektplanung in einem geeigneten Ausmaß
- Management von Veränderungen im Projekt
- Aufbau einer geeigneten Projektorganisation und von geeigneten Kommunika­tionsstrukturen
- Sicherstellung der erforderlichen Einbindung des Managements sowie von Sta- keholdern, die fuör den Projekterfolg relevant sind
- Bewaltigung von Krisen und Diskontinuitäten bei der Projektdurchfuhrung
- Management der Beziehungen des Projektes zu sozialen Umwelten sowie der inhaltlichen und zeitlichen Beziehungen und Abhöangigkeiten“ [HH11, S. 24]

Es ist allerdings zu beruöcksichtigen, dass der Inhalt eines Projekts in direktem Zusammenhang mit der Kundenzufriedenheit steht, so dass ein Projekt dem vor­gegebenen Inhalt nach zwar als erfolgreich angesehen werden koönnte, gleichzeitig ist es jedoch moöglich, den Erfolg im Sinne der Kundenzufriedenheit zu verfehlen und umgekehrt. [Joh18, S. 14] [AE13a, S. 60]

2.1.1 Vorgehen und Aufgaben im Projektmanagement

In der Regel folgen - sofern uberhaupt eine Struktur zu Grunde gelegt wird - alle Projekte einem aähnlichen Schema, das sich von Vorbereitung bzw. Planung uäber die Durchfuährung und dem kontinuierlichen Monitoring der Aktivitaäten bis zum Abschluss eines Projekts erstreckt⁴ [Boh10, S. 12] [Jak15, S. 28-29]. So gehoären zu einer Projektplanung zum Beispiel verschiedene Elemente: Die wesentlichen sind Projektstruktur und -ablauf, Projektorganisation, Zeit- und Kostenpläane sowie Personal- und Materialbedarfe. Waährend der Durchfuährung eines Projekts muässen insbesondere inhaltliche Aufgaben unter Beruäcksichtigung von Regeln und Vorga­ben erfuällt werden; gleichzeitig muässen Informationsfluässe zu Abstimmungs- oder Reportingzwecken geregelt sein. [Klo09, S. 35 ff.], [NS14, S. 264 ff.] Zur Verein­heitlichung dieser Instrumente lassen sich Vorgehensmodelle beschreiben, die ein Geruäst zur Projektdurchfuährung darstellen, das wesentliche Techniken bereitstellt und gleichzeitig fuär Vergleichbarkeit und Transparenz sorgt [AE13a, S.62]. Einige davon sollen im Folgenden exemplarisch beschrieben werden.

PM-Vorgehensmodelle

Vorgehensmodelle sind dazu geeignet, Komplexitäat in Projekten zu reduzieren, in­dem Erkenntnisse aus einer Vielzahl vergangener Projekte zu einer Art Leitfaden fuär zukuänftige Projekte systematisiert zusammengefasst werden [PR11, S. 170]. Allerdings ist zu beruäcksichtigen, dass die Anwendung eines Modells nicht auto­matisch Erfolg herbeifuährt [HK15, S. 21]. Es lassen sich klassische, moderne und agile Vorgehensmodelle unterscheiden [AS14, S. 140].

Klassische Modelle

Zu den klassischen Modellen gehoären so genannte phasenorientierte oder se­quentielle Vorgehensmodelle, die sich in zeitlich begrenzte, nacheinander zu durch­laufende Phasen gliedern. Diese sind in der Regel dadurch gekennzeichnet, dass eine Projektphase erst nach vollstaändiger Fertigstellung der vorhergehenden star­ten kann. [Boh10, S. 27-28] Am Ende jeder Phase erfolgt anhand vorab definier­ter Meilensteine eine Fortschrittskontrolle [PR11, S. 171], die im Rahmen einer ausfuährlichen Planung zu Projektbeginn festgelegt wurden; auf Grund der inhalt­lichen Abhäangigkeit zwischen den Phasen fuährt eine Verzäogerung in einer Phase auch zu Verschiebungen in den nachgelagerten Phasen. [Hof08, S. 5]. Die Planung solcher Projekte ist nur dann moäglich, wenn zu Projektbeginn bereits alle relevan­ten Faktoren bekannt sind [Boh10, S. 37]. Ein dediziertes PM-Vorgehensmodell ist zum Beispiel PRINCE2⁵, das Prozesse, Phasen, Komponenten und Techniken beschreibt [LR08, S. 69].

Ein weiterer bekannter Vertreter phasenorientierter Vorgehensmodelle aus der Softwareentwicklung ist das Wasserfallmodell. Jede der Phasen ist waührend der Projektabwicklung einzigartig [Hof08, S. 5] und lehnt sich an die Phasen der Pro­duktentwicklung an [Gol11, S. 84]. Vollstüandiger Abschluss und Freigabe sind je­weils die Voraussetzung fuür den Uübergang in die nüachste Phase [SDW+10, S. 48]. Weil die Phasen nacheinander durchlaufen werden, werden viele grundsaützliche Aspekte bereits in den fruühen Phasen festgelegt. Dadurch kann auf Weiterent­wicklungen oder andere neue Erkenntnisse außerhalb des Projekts nur schwer rea­giert werden. [GH15, S. 59] Eine weiterentwickelte Form des Wasserfallmodells ist das Schleifenmodell. In diesem Modell küonnen Phasen ineinander uübergehen [PR11, S. 171], weil Ruückfuührschleifen immerhin das Einfließenlassen von Erkennt­nissen aus einer Phase in die Ergebnisse der vorhergehenden Phase und damit ein Zuruückkehren in diese ermüoglichen [Gol11, S. 86].

Moderne⁶ Modelle

Zu den so genannten modernen Vorgehensmodellen gehoüren unter anderem das V-Modell⁷ und das Rational-Unified-Process-Modell (RUP-Modell), die auch als obj ektorientierte Modelle zur Softwareentwicklung bezeichnet werden [NS99, S. 166]. Beide haben einen hohen Dokumentationsaufwand, der sich jeweils aus dem großen Umfang ergibt [Kle11, S. 42]. Im V-Modell wird das Gesamtergebnis eines Projekts vom Auftrag ausgehend in einzelne Einheiten zerlegt, die dann umge­setzt ( analytische Phasen ) und wieder integriert ( synthetische Phasen ) werden [SDW+10, S. 50]. Die Phasen werden nacheinander durchlaufen, an deren Enden stehen entsprechende Zwischenergebnisse; abgesehen davon umfasst es Rollen und Aktivitaüten [PR11, S. 182-183]. Bestimmte Elemente sind obligatorisch, wüahrend andere wahlweise zum Einsatz kommen ( Tailoring ) [SDW+10, S. 52-54].

Das RUP-Modell ist eine strukturierte Zusammenstellung von Best-Practice­Prozessbeschreibungen. Diese bestehen analog zum V-Modell aus Aktivitaüten, Rollen sowie Eingangs- und Ausgangsgroüßen einzelner Aktivitaüten. [HBW07, S. 7] Im Gegensatz zum V-Modell sind Iterationen erlaubt, allerdings nur innerhalb der einzelnen Phasen [SH05, S. 221]; eine Iteration dient dabei der Verbesserung des vorherigen Ergebnisses [Kle11, S. 41]. Auf Grund dieses schrittweisen Vorge­hens wird das RUP-Modell auch als inkrementeller Ansatz bezeichnet [SDW+10, S. 56]. Fuür jedes neue Projekt sind aus der umfangreichen Prozesssammlung des Modells die auf die individuelle Problemstellung passenden Elemente auszuwaühlen und modular anzuwenden. Das RUP-Modell basiert auf so genannten Use Cases⁸. [HWB05, S. 314] Insbesondere in Softwareentwicklungsprojekten besitzt es Vortei­le durch seine Verknuüpfung mit der UML⁹ -Diagrammfamilie [SDW+10, S. 61].

Agile Modelle

Agile Vorgehensmodelle werden auch leichtgewichtige Modelle genannt; we­sentliche Vertreter sind zum Beispiel Extreme Programming (XP) oder Scrum, die ebenfalls aus der Softwareentwicklung stammen [PR11, S. 184]. Sie zeichnen sich dadurch aus, dass die konkrete Planung spöterer Aufgaben erst wöhrend der Durchfuhrung des Projekts erfolgt [Hof08, S. 6]. Daher sind sie fur die Abwicklung komplexer Projektaufgaben geeignet, deren Anforderungen nicht von Beginn an vorliegen [Hab13, S. 96]. In beiden Vorgehensmodellen findet eine standige Invol- vierung des Kunden statt, bei XP ist ein Kundenvertreter sogar Teil des Projekt­teams. Ahnlich wie im RUP-Modell werden die Anforderungen aus Anwendersicht in Form von User Stories festgehalten. [Kle11, S. 46-47]

Bei Scrum handelt es sich um ein Metamodell; das heißt, dass nur der Rahmen¹⁰ eines Projektes vorgegeben wird, wahrend die Detaillierung der tatsachlichen Auf­gaben offen bleibt [Kle11, S. 45]. Es basiert auf einem Prozess, der alle zwei bis vier Wochen iterativ durchlaufen wird, an dessen Beginn eine Planung der Folgeitera­tion und an dessen Ende die Lieferung eines (Teil-)Ergebnisses stehen. Weiterhin sind Rollen und Elemente - so genannte Artefakte - definiert. [GM14, S. 55] Scrum erreicht die Fokussierung auf den Kundennutzen durch die drei Grundsatze Visi­bility, Inspection und Adaption (vgl. Abschnitt 2.3) [Sch04, S. 28-46].

Zusammenfassend lassen sich die eher klassisch orientierten und die agilen Vor­gehensmodelle auf der Basis einiger Grundannahmen wie folgt voneinander ab­grenzen (vgl. Tabelle 2.1) [Hab13, S. 97]. Detaillierte Ausfuhrungen zum Thema Agilitat folgen in Abschnitt 2.3.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1. Grundannahmen in klassischen und agilen Vorgehensmodellen Quelle: Leicht abgewandelt entnommen aus HabERmaNN (2014, S. 97).

PM-Dimensionen

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2. Handlungsfelder im Projektmanagement

Quelle: Eigene Darstellung nach Ahlemann (2013, S. 140).

In Abhängigkeit des gewählten Vorgehensmodells lassen sich im Rahmen des Projektmanagements verschiedene Handlungsfelder beschreiben. Ahlemann (2013, S. 140) fuhrt zunächst die folgenden an (vgl. Abbildung 2.2) [AE13b, S. 140]:

Strategie Projekte dienen der Umsetzung von Strategien, sind also in einen ent­sprechenden Kontext einzuordnen. Dies kann erfolgen, indem Projektziele de­finiert werden, die sich von strategischen Zielen ableiten lassen bzw. diese ope­rationalisiert.

Effektivität Wie zu Beginn des Abschnitts 2.1 angesprochen wurde, ist der Zu­friedenheit des Kunden - unabhangig davon, ob es sich um einen internen oder externen Kunden handelt - besondere Aufmerksamkeit zu schenken und das Projekt ist entsprechend zu steuern.

Orgänisätion Sobald mehrere Projekte gleichzeitig abgewickelt werden, ist die Schaffung von Transparenz in Bezug auf deren Abhangigkeiten unabdingbar. Dazu ist es notig, Projekte in Strukturen der Organisation einzubetten, die diese Aufgabe erfullen (z.B. durch Schaffung dedizierter Koordinationsstellen).

Controlling Die Feststellung des Projektfortschritts kann mit Hilfe verschiedener Instrumente (z.B. Projektberichte, Besprechungen) erfolgen. So kann festge­stellt werden, ob das Projekt weiterhin seinen Vorgaben genugt. Ist dies einmal nicht der Fall, mussen Regeln existieren, die eine Eskalation erlauben.

Personäl Eine wesentliche Aufgabe, die vor Beginn eines Projekts zu erledigen ist, besteht in der Ausstattung des Projekts mit dem geeigneten Personal. Dabei sind nicht nur die fachlichen Kompetenzen relevant, sondern insbesondere auch die methodischen und persönlichen Qualifikationen im Projektmanagement.

Kultur Funktionierende Projekte zeichnen sich durch eine Kultur aus, die durch bestimmte Merkmale geprägt ist. Dazu zahlen unter anderem die Zusammen­arbeit innerhalb des Projektteams , eine konstruktive Fehlerkultur als Basis der Weiterentwicklung sowie eine offene und transparente Atmosphäre.¹¹

Ergaünzend zu den beschriebenen Handlungsfeldern von Ahlemann (2013, S. 140.) schlagen Kuster et al. (2006, S. 8-9) zur Betrachtung von Projektmana­gement vier Dimensionen vor: Funktional, institutionell, instrumentell sowie per­sonell, psychologisch und sozial (vgl. Abbildung 2.3).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3. Dimensionen im Proj ektmanagement

Quelle: Eigene Darstellung in Anlehnung an Kuster et al. (2006, S. 8-9).

Funktionale Dimension

Wie in den Handlungsfeldern Strategie und Effektivität bereits erwahnt wurde, ist es fuür die erfolgreiche Durchfuührung eines Projekts notwendig, ein Proj ekt- ergebnis und die wichtigsten Anforderungen“ zu kennen, das die Unternehmens­strategie unterstuützt“ [Boh10, S. 36]. Im ersten Schritt muss dazu die Vision des Auftraggebers verstanden und in Ziele¹² uüberfuührt werden, die sich anschließend noch weiter operationalisieren lassen [Rei09, S. 7]. Quellen zur Bewertung des Zu­sammenhangs mit der Strategie sind zum Beispiel Visionen, Leitbilder und andere strategische Dokumente [PR11, S. 85].

Ein Projekt wird stets von vielen Akteuren und Faktoren beeinflusst; folglich ist es außerdem von großer Bedeutung, das Projektumfeld mit allen Randbedingun­gen zu verstehen [Boh10, S. 36]. Eine entsprechende Analyse hilft allen Beteiligten, diesbezuüglich auch eine gemeinsame Sicht zu schaffen [KW10, S. 67]. Neben der Zuordnung zum internen oder externen Projektumfeld kann dabei eine Unterschei­dung der relevanten Einfluüsse nach sachlichen (fachlich/inhaltlich) und sozialen (organisatorisch/menschlich/sozial) Gesichtspunkten erfolgen. Diese Betrachtung erfolgt aus Sicht des Projekts (vgl. Abbildung 2.4). [GG09, S. 88-91]

Wegen des zu Beginn dieses Kapitels beschriebenen Wesens von Projekten weisen diese ein wesentlich hoüheres Risikopotenzial auf als Routinetaütigkeiten“ [SOP05, S. 149]. Die fachlichen und inhaltlichen Einfluüsse lassen sich als Risiken im Hinblick auf das bereits erwaühnte Magische Dreieck“ aus Inhalt, Zeit und Kosten bezeichnen [Tec06, S. 127]. Um durch Gegenmaßnahmen die Eintrittswahrschein­lichkeit senken oder die Auswirkungen von eingetretenen Risiken minimieren zu koünnen, ist zur Durchfuührung des Projekts eine Risikoanalyse notwendig [Klo09, S. 26-27], [Rei09, S. 32-34], [Rez07, S. 95].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4. Einfluösse im Umfeld eines Projekts

Quelle: Eigene Darstellung in Anlehnung an GPM (2009, S. 88).

Die relevanten Stakeholder koönnen aus den organisatorischen, menschlichen und sozialen Einfluössen im Rahmen der Umfeldanalyse (vgl. Abbildung 2.4) identifi­ziert werden. Unter Stakeholdern werden dabei alle Personen oder Personengrup­pen verstanden, die entweder vom Projekt betroffen oder am Projekt beteiligt sind. Stakeholder sind also sowohl innerhalb als auch außerhalb der projektgeben­den Organisation zu finden. [Boh10, S. 24] Relevant in der Stakeholderbetrachtung sind vor allem das Einflusspotential, der Grad der Betroffenheit und die Einstel­lung gegenuöber dem Projekt [PMI13, S 391], so dass systematisch auf diese ein­gewirkt werden kann [Boh10, S. 36]. Eine visuelle Darstellung zur Verdeutlichung von Abhaöngigkeiten ist moöglicherweise ebenfalls sinnvoll. [GG09, S. 94]

Institutionelle Dimension

In der institutionellen Dimension sind bei der Gruöndung einer Projektorgani­sation verschiedene Rollen zu besetzen. Je nach gewaöhltem Projektmanagement­ansatz bzw. Vorgehensmodell köonnen dies zum Beispiel die folgenden sein: Pro­jektauftraggeber oder Kunde, Projektsponsor, Projektlenkungsausschuss, Projekt­leiter, Projektteammitglied, Projektmitarbeiter [Boh10, S. 25-27], [GG07, S. 237], [Ste14, S. 64-67], Scrum Master, Product Owner, Entwicklungsteammitglied [SS17, S. 6-7]. Somit erfolgt die bereits im Handlungsfeld Organisation angesprochene Einbettung in die Gesamtorganisation (vgl. auch Abschnitt 2.2).

Zur Steuerung eines Projekts sind neben der Projektorganisation auch Regelun­gen hinsichtlich des Vorgehens bei der Loösungsfindung zu treffen [Klo09, S. 137]. Aus diesem Grund ist neben der Aufbauorganisation in Abhaöngigkeit des Projekt- typs auch die Ablauforganisation zu definieren [PR11, S. 33]. Um eine gute Basis für die Zusammenarbeit zu schaffen, empfiehlt sich außerdem die Definition von Entscheidungskompetenzen und Verantwortlichkeiten hinsichtlich der im Rahmen der Aufbau- und Ablauforganisationen definierten Rollen und Aufgaben [HW17, S. 44], [WW06, S. 137].

Instrumentelle Dimension

Projektmanagement lasst sich an Regeln und Vorgaben orientieren, die oft von nationalen und internationalen Normen abgeleitet und in organisationsspezifischen Regelwerken festgehalten werden [PR11, S. 41]. Haufige Grundlagen bilden zum Beispiel die DIN-Norm 69901:2009¹³, die IPMA Competence Baseline (ICB) der International Project Management Association (IPMA¹⁴) [GG09, S. 3] oder der PMBOK® Guide des Project Management Institutes (PMI)¹⁵ [PMI13]. Derar­tige Regelwerke versuchen, in dem heutzutage etwas unubersichtlichen Feld des Projektmanagements eine Standardisierung zu erreichen, um den Überblick zu vereinfachen und Einstiegshurden zu senken [Jak15, S. 33].

Regeln und Vorgaben sowie geeignete Methoden und Hilfsmittel kännen dabei helfen, den Fortschritt - wie im Handlungsfeld Controlling bereits angesprochen - eines Projekts festzustellen. Je nach Vorgehensmodell bieten unter anderem Pro­jektmanagementorganisationen wie die IPMA (2009) oder das PMI (2013) in ihren oben genannten Regelwerken Methoden und Hilfsmittel zur Planung, Steue­rung und Durchfuhrung von Projekten an. Daruber hinaus lassen sich in der Litera­tur zahlreiche Autoren finden, die entsprechende Sammlungen angefertigt haben¹⁶. Zusatzlich sind im agilen Kontext weitere Techniken dazugekommen¹⁷.

Die Qualität eines Projektteams lässt sich weder durch zuvor angesprochene Me­thoden und Hilfsmittel noch durch Software ersetzen. Beides kann das Projektma­nagement lediglich unterstutzen. Allgemeine Office-Anwendungen sind dabei ein erster Schritt, um Listen anzufertigen oder Termine und Kosten nachzuverfolgen. [Mad17, S. 644-646] Ein wesentlicher Grund fur die Anwendung von PM-Software sollte die Schaffung von Transparenz sein. Ein wesentlich mächtigeres Werkzeug zur Planung und Steuerung von Projekten ist zum Beispiel das Microsoft™-Produkt Project (MS-Project). [Jak15, S. 379 ff.] Auch in Bezug auf Software wurden im Zusammenhang mit agilen Ansatzen Werkzeuge geschaffen. Dazu gehort unter an­derem das Atlassian-Produkt JIRA¹⁸.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.5. Notwendige Inputfaktoren zur Problemlüosung

Quelle: Entnommen aus Heyen (1980, S. 7).

Im Handlungsfeld Personal wurde bereits die Zusammensetzung einer Pro­jektorganisation aus geeigneten Kompetenztrüagern thematisiert. Neben fachlichen Qualifikationen ist es notwendig, Proj ekte abwickeln zu koünnen. Dazu küonnen un­ter anderem Fuühren ohne disziplinarische Macht, Moderation von verschiedenen Interessensgruppen oder Reagieren auf unerwartete Ereignisse gehoüren. [HK15, S. 25] Als gedankliche Grundlage fuür die Gruündung einer Proj ektorganisation kann ergaünzend die Abbildung 2.5 herangezogen werden, die zeigt, dass fachli­che oder methodische Qualifikationen zur Problemlüosung nicht immer ausreichen. Aus diesem Grund ist es notwendig, jeweils bereichsuübergreifende oder interdis- ziplinaäre Projektorganisationen zusammenzustellen, die daruüber hinaus zum Bei­spiel uüber Kenntnisse von Situation, Arbeitstechniken und psychologischen Aspek­ten verfuügen. [Hey80, S. 7]

Der Begriff Kompetenz adressiert in diesem Zusammenhang jedoch nicht nur die Faühigkeiten in Bezug auf Fach- und Projektmanagementkenntnisse von Pro­jektmitarbeitern, sondern meint auch die Kompetenz des Unternehmens, Proj ekte tatsaüchlich zuzulassen. Das bedeutet, die Unternehmenskultur (vgl. 2.2.2) ist da­durch gekennzeichnet, dass die Notwendigkeit von Projekten nicht nur theoretisch verstanden wurde. [HK15, S. 24] Sonst wird es dazu kommen, dass hinsichtlich eines Projekts Aufgabe, Verantwortung und Vollmacht (. . . ) sowie die Abgren­zung zu den Fachbereichen (. . . ) nicht eindeutig geregelt sind“. Um dieses Problem aufzuloüsen, sollte zunüachst die organisatorische Einbindung von Projekten geklüart sein (vgl. Abschnitt 2.2.1). [Mad17, S. 607-608]

Im Handlungsfeld Kultur wurde bereits die Zusammenarbeit angesprochen, die sich bis zu einem bestimmten Grad institutionalisieren laüsst (vgl. Abschnitt In­stitutionelle Dimension ). Daruber hinaus sollte jedoch - sofern möglich - schon bei der Gruündung des Proj ektteams darauf geachtet werden, dass die einzelnen Mitglieder zusammenpassen“ (Arbeitsweise, Typ) und es sollte insbesondere bei neuen Teams genug Raum fuür Teambildung vorhanden sein [HW17, S. 48]. Sonst koünnen zum Beispiel Konflikte und Widerstaünde entstehen, die im Rahmen des Projektmanagements wieder aufgeloüst werden muüssen [PR11, S. 38]. Eine wesent­liche Komponente der Zusammenarbeit ist Kommunikation. Auch diese kann zwar geregelt werden [HW17, S. 53 ff.], doch in jedem Fall ist der Faktor Mensch zu berücksichtigen [KHL+06, S. 175].

Wie im Zusammenhang mit Kompetenzen schon erwähnt, spielt Führung im Projektmanagement eine wesentliche Rolle. Die Art der Führung ist dabei abhängig vom Vorgehensmodell (2.1.1) innerhalb des Projekts sowie von Ein­bindung des Projekts in die Gesamtorganisation (vgl. Abschnitt 2.2.1). Klo­se (2009, S. 135) führt beispielsweise folgende Inhalte von Führung in Projek­ten an, die zur Motivation der Teammitglieder beitragen können: „Offenheit und Gesprachsbereitschaft signalisieren, zum Mitdenken motivieren, Selbstständigkeit fordern, Verantwortung zuteilen (klare Grenzen setzen), Mitspracherecht und Ent­scheidungsspielraum fuär den Einzelnen einraäumen, Ergebniskontrolle statt Verfah­renskontrolle, Engagement zeigen, persoänliche Weiterentwicklungsmoäglichkeiten bieten, Tadel und Lob verteilen, Teamgeist fäordern, oäffentliche Kritik Einzelner vermeiden, Einzelne nicht persoänlich angreifen, keine Ausgrenzungen von Beteilig­ten (alle angemessen beteiligen), gelegentlich auch persäonliche Themen ansprechen, Erfolge . feiern k.“

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.6. Dimensionen im Projektmanagement

Quelle: Eigene Darstellung in Anlehnung an Ahlemann (2013, S. 140), Kuster et al. (2006, S. 8-9).

Zusammenfassend ist festzuhalten, dass sich die Handlungsfelder von Ahle­mann (2013, S. 140) in die Dimensionen von Kuster et al. (2006, S. 8-9) uäberfuähren lassen, so dass weitere Aspekte ergäanzt werden koännen. Wie Abbil­dung 2.6 entnommen werden kann, umfasst die funktionale Dimension die sachli­chen Aspekte des Projekts wie Inhalt und Risiken, waährend die institutionelle Di­mension den Aufbau der Projektorganisation sowie die Einbindung des Projekts in die Gesamtorganisation beschreibt. Die instrumentelle Dimension enthaält vor allem die technischen Elemente wie Regeln, Methoden und (IT-)Hilfsmittel. Eine wesentliche Rolle spielt die personelle, psychologische und soziale Dimension, die sich mit dem Zusammenspiel von Menschen innerhalb eines Projekts beschaftigt (vgl. auch Abschnitt 2.2.2).

2.1.2 Erfolgsfaktoren im Projektmanagement

Im vorherigen Abschnitt 2.1.1 wurden die verschiedenen Dimensionen des PM dar­gestellt. „Durch die Wahrnehmung von Projekten als temporare Organisationen erhalten Projekte eine eigene Identitat, die sich besonders in den Projektzielen, der Projektorganisation und der Projektkultur widerspiegelt.“ [HH11, S. 21] Dem­zufolge lassen sich drei Ebenenen unterscheiden, auf denen sich Projekterfolg zeigt [HK15, S. 19-25]:

- Formale Ebene
- Organisatorische Ebene
- Kompetenzebene

Obwohl der Schwerpunkt der vorliegenden Arbeit auf den Kriterien fur erfolgrei­ches bzw. weniger erfolgreiches Projektmanagement im agilen Kontext liegt, sollen im nachsten Schritt die allgemeingultigen Erfolgsfaktoren fur Projektmanagement naher untersucht werden, um die Ergebnisse den folgenden Untersuchungen zu Grunde legen zu konnen. Dazu werden die Dimensionen von Projektmanagement in die Ebenen des Erfolgs uberfuhrt (vgl. Abbildung 2.7). Desweiteren werden die einzelnen Erfolgfaktoren von 1 bis 23 nummeriert (zur Entstehung vgl. Anhang B.4), um im weiteren Verlauf der Arbeit auf einfache Art und Weise einen Zusam­menhang herstellen zu kännen:

Formale Ebene

Auf formaler Ebene werden die inhaltlichen Aspekte des Projekts wie Projektziele sowie die Einordnung in die Umwelt betrachtet. Folgende Erfolgsfaktoren lassen sich auf der Basis der bisherigen Betrachtungen herleiten:

Strategie und Projekt bilden eine Kausalkette. (1) Wesentlich fur den Pro­jekterfolg ist die Akzeptanz des Projektgegenstands innerhalb der Organisation [FR10, S. 14]. Der Zusammenhang zwischen Unternehmensstrategie und Pro­jekten kann maßgeblich dazu beitragen (strategic alignment ) [DB14, S. 402].

Es herrscht Klarheit bei Änderungen. (2) Es ist denkbar, dass Ziele sich wahrend der Durchführung eines Projekts ändern [Klo09, S. 21, 32-33]. Solche veränderten Anforderungen fuhren zu einer zusatzlich erhähten Komplexität, die den Projekterfolg gefahrden kann. [RSW15, S. 13]

Das Projekt orientiert sich an Kundenbedürfnissen. (3) Es ist zu beach­ten, dass zum Beispiel die Anforderungen des Auftraggebers nicht in jedem Fall eindeutig aus Auftragsdokumenten hervorgehen [Klo09, S. 21, 32-33]. Auch nur angenommene Kundenbedurfnisse stellen ein Risiko dar [vHMS04, S. 168].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.7. Ebenen von Erfolgsfaktoren im Proj ektmanagement

Quelle: Eigene Darstellung in Anlehnung an Ahlemann (2013, S. 140), Kuster et al. (2006, S. 8-9), Heintel (2015, S. 19-25).

Die Projektziele sind transparent. (4) Eine weitere wesentliche Ursache fuär das Scheitern von Projekten besteht in nicht ausreichend definierten Projekt­zielen und der daraus resultierenden Unklarheit in Bezug auf sich ergebende Aufgaben [HK15, S. 19-22] [Hey80, S. 6].

Der Umgang mit Risiken ist geregelt. (5) Keine Planung schuätzt vor Ein- fluässen, die erst im Projektverlauf zum Problem werden [Klo09, S. 160], zum Beispiel Gesetzesaänderungen [Tec15, S. 40]. Ein strukturierter Umgang mit sol­chen Risiken ist noätig [MR16, S. 151].

Der Umgang mit Stakeholdern ist geregelt. (6) Stakeholder, wie z.B. der Auftraggeber, spielen eine wichtige Rolle beim Verstehen der Anforderungen [HKW+13, S. 32]. Regelmaäßiger Kontakt ermoäglicht, Informationen bereitzu­stellen und Wuänsche, Anregungen und Kritik“ aufzunehmen [Klo09, S. 160].

Organisatorische Ebene

Auf organisatorischer Ebene sind auf der Basis der vorherigen Abschnitte vor allem die Aspekte zu betrachten, die fuär den Aufbau einer Projektorganisation relevant sind. Dazu gehäort auch die organisatorische Einbindung in das Umfeld.

Die Ergebnisverantwortung ist klar zugeordnet. (7) Es ist klar zuzuord­nen, wer die Verantwortung fuär das Projektergebnis traägt [WM11, S. 120]. Dies sollte unter anderem in Abhaängigkeit von der Eingliederung der Projekt­organisation in die Gesamtorganisation geschehen (vgl. Abschnitt 2.2.1).

Es besteht Rollenklarheit. (8) Die Gruündung einer klaren Projektorganisati­on spielt eine ebenso große Rolle wie die eindeutige Kommunikation. Ohne entsprechende Transparenz ist das Risiko fuür Reibungsverluste oder Absto­ßungsreaktionen hoch. [HK15, S. 22-24], [WW06, S. 137]

Die Ressourcenzuordnung erfolgt stringent. (9) Ressourcen küonnen leicht zu Engpaüssen werden und ihre Knappheit fuührt schnell zu Verzoügerungen. Ins­besondere der Beginn neuer Projekte ohne Ruücksicht auf bereits begonnene fuührt zu einer Vervielfachung des Ressourcenproblems. [Tec15, S. 16-17]

In der Organisation existiert Rückhalt. (10) Ruckhalt konnte unter ande­rem durch einen Projektsponsor sichergestellt werden. [Boh10, S. 36] Dabei ist festzuhalten: Je komplexer ein Projekt ist, desto wichtiger wird die Invol- vierung des oberen Managements. [WM11, S. 21]

Die Entscheidungskompetenz ist klar zugeordnet. (11) Verbunden mit der Verantwortung fuür das Projekt ist eine klare Zuordnung der Entscheidungskom­petenz. Wer (beispielsweise) fuür die Einhaltung von Terminen verantwortlich ist, sollte auch bei deren Festlegung mitwirken (. . . )“ [Ste14, S. 64].

Es existiert eine hinreichende Projektfinanzierung. (12) In Bezug auf das magische Dreieck (vgl. Abschnitt 2.1) darf nicht außer Acht gelassen werden, dass ein weiterer wichtiger organisatorischer Aspekt in einer gesicherten Finan­zierung besteht [Boh10, S. 36].

Informationsflüsse funktionieren. (13) Um Storungen wie Missverstündnisse, Doppelarbeit oder fehlende Akzeptanz zu vermeiden, sind Informationsfluüsse sorgfaültig zu regeln. Extremfüalle (. . . ) sind(...) zu wenig Informationen oder zu viel Informationen“ [Klo09, S. 145].

Regeln und Vorgaben werden eingehalten. (14) Eine entscheidene Randbe­dingung besteht darin, ob und inwiefern Standards und Richtlinien, die das Projekt beachten muss“, transparent sind, so dass auch die Einhaltung¹⁹ gewüahrleistet werden kann [Boh10, S. 36].

Regeln und Vorgaben existieren als Handlungsrahmen. (15) Im Rahmen der Loüsungsfindung kann nicht auf Standards oder andere Orientierungshilfen zuruückgegriffen werden. Um Willkuür und Zufall zu unterbinden, hilft die Eta­blierung eines Handlungsrahmens zur Abwicklung. [FR10, S. 16]

Es existiert eine einheitliche Vorgehensweise. (16) Eine einheitliche Spra­che“ auf der Basis eines gemeinsamen Grundmusters“ vereinfacht die Zusam­menarbeit. Transparenz wird dadurch erhüoht, so dass es zum Beispiel bei per­sonellen Aünderungen weniger zu Problemen kommt. [Hey80, S. 6]

Kompetenzebene

Auf Kompetenzebene konnte herausgearbeitet werden, dass sowohl die Faähigkeiten der einzelnen Projektmitglieder als auch die Kompetenzen der Organisation als Zusammenschluss fuär den Projekterfolg eine Rolle spielen.

Es sind ausreichend Kompetenzen vorhanden. (17) Bei der Gruändung der Projektorganisation ist auf die verschiedenen Qualifikationen der Mitglieder zu achten. Diese sollten speziell auf die Projekterfordernisse zugeschnitten sein. [MOS93, S. 86], [Bor1”3, S. 135]

Die organisationale Einbindung ist gegeben. (18) Abhaängig von dem Pro­jekt (Art, Umfang, Ziel) sowie von der Unternehmens- und Projektkultur ist die Einbindung der Projekt- in die Gesamtorganisation zu regeln (vgl. 2.2.1), um zum Beispiel formale Weisungsbefugnisse festzulegen [KHL+06, S. 94].

Es herrscht ein offenes Miteinander. (19) Eine Verhaltenskompetenz im Zu­sammenhang mit Projekten ist Offenheit. Dazu gehoärt, Einwaände und Anre­gungen einerseits ansprechen zu käonnen und sie andererseits auch gegenseitig ernst- und anzunehmen. Vertrauen ist dafuär eine wichtige Basis. [Jen09, S. 282]

Es existiert eine Fehlerkultur. (20) Grundlegend fuär eine Fehlerkultur ist die Einstellung zum Miteinander. Dieser Einstellung liegt die Bereitschaft zu Grunde, in einem kontinuierlichen Prozess das eigene Denken zu (. . . ) hin­terfragen und die Rolle des Lernenden (. . . ) anzunehmen.“ [Ben11, S. 11-12]

Die Führung im Projekt ist adäquat. (21) Zur Führung gehort im Projekt­management die Fuährung sowohl des Teams als auch der einzelnen Mitglieder [Kuän16, S. 48]. Sie muss zur Situation passen, die zum Beispiel durch Team- groäße und Rahmenbedingungen des Projekts gepräagt ist [Wal06, S. 48-49].

Kommunikation funktioniert. (22) Die Kommunikation im Team sollte kein zufaälliges Ergebnis des Projekts sein. [Hey80, S. 67] Sonst gelingt es zum Bei­spiel nicht, den Teammitgliedern Gesamtzusammenhaänge zu verdeutlichen, wo­von die Identifikation mit den Projektzielen abhaängig ist [KW10, S. 19-20].

Es existiert Raum für Teambildung. (23) Arbeiten Projektteams erstmalig zusammen, ist ausreichend Zeit fuär die Teambildung einzuräaumen, da die Zu­sammenarbeit einen signifikanten Beitrag zu Erfolg oder Misserfolg eines Pro­jekts leistet [HW17, S. 48].

In Tabelle 2.2 wurden die zuvor erlaäuterten Erfolgsfaktoren des Projektmanage­ments noch einmal uäbersichtlich zusammengefasst. Die Zuordnung zu den drei vor­gestellten Ebenen und die Nummerierung wurden dabei uäbernommen. Zusaätzlich wurde jeweils ein Stichwort ergaänzt, das den Aspekt benennt, zu dem ein Erfolgs­faktor gehoärt (siehe zweite Spalte von links).

Die Erfolgsfaktoren bilden zusammen mit den folgenden Abschnitten zur Ein­bettung von Projekten in unternehmerische Strukturen (vgl. Abschnitt 2.2)und zum Agilen Management (vgl. Abschnitt 2.3) die Grundlage fuär die Ausarbeitung der Kriterien zur Beurteilung der Agile-Fäahigkeit“ eines Unternehmens in Ab­schnitt 4.1.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2. Erfolgsfaktoren im Projektmanagement

2.2 Unternehmen als Umfeld von Projekten

Unternehmen sind betriebswirtschaftliche Akteure, die je nach ihrer Art Produkte herstellen oder Dienstleistungen erbringen. Die konkreten Ziele eines Unterneh­mens bestimmen dann dessen langerfristige Aktivitaten. Wirtschaftlichkeit stellt in diesem Zusammenhang einen zentralen Aspekt dar, weil sie das Überleben eines Unternehmens sicherstellt [Hei85, S. 17-33]. Der Wert eines Produktes oder einer Dienstleistung lasst sich jedoch aus verschiedenen Blickwinkeln betrachten. Dazu gehoren zum Beispiel die Erzielung von Umsatz, die Neukundengewinnung oder eine Vertiefung in technologischer Hinsicht. [Wat17, S. 65]

Zur Erreichung der Unternehmensziele künnen also ganz unterschiedliche Auf­gabenstellungen entstehen. Die meisten davon besitzen einen regelmaßigen Cha­rakter, der Aufbau des Unternehmens orientiert sich an ihnen und Prozesse werden entsprechend standardisiert und optimiert. [Jak15, S. 111] Andere Aufgaben sind einmalig und nur auf eine bestimmte zeitliche Dauer ausgelegt. Diese zumeist kom­plexeren Themen, verbunden mit einer konkreten Aufgabenstellung sowie festge­legten Termin- und Budgetvorgaben, unterliegen anderen organisatorischen Regel­werken und sollten - wie in Abschnitt 2.1 bereits erwahnt - als Projekt abgewickelt werden. [Boh10, S. 12-19], [Ste14, S. 10], [WW06, S. 137]

Projektorganisationen dienen also dem Zweck, „die Organisationsschwachen der funktional-burokratischen Hierarchie organisatorisch zu uberwinden“ [HK15, S. 23]. „Projekte setzen wegen ihres interdisziplinüren Charakters (allerdings) eine vorubergehende organisatorische Eingliederung und Anderung voraus und damit verbunden eine Teilung der Verantwortung und Vollmachten zwischen Projekt- und Fachbereich.“ [Mad17, S. 5] Aus diesem Grund ist sorgfaltig zu uberlegen, wie Projekte in die bestehende Organisation eingegliedert werden künnen.

2.2.1 Mögliche Formen der Integration

Im Folgenden werden drei etablierte Formen der Einbindung von Projektorga­nisationen (PO) in die so genannte Linienorganisation²⁰ von Unternehmen kurz dargestellt²¹:

- Reine PO oder Projektbasierte Organisation
- Matrix-PO
- Stabs-PO oder Einfluss-PO oder Linienorganisation

Bei der Darstellung handelt es sich in der Regel lediglich um formelle Strukturen, die in einer realen Umwelt unternehmensindividuell angepasst werden und damit den tatsächlichen Strukturen weichen [Rob15, S. 33-34].

Reine Projektorganisation

Eine reine PO agiert selbstaändig innerhalb einer Gesamtorganisation und parallel zur Linienorganisation (vgl. Anhang B.1), so dass eine Organisationseinheit je Pro­jekt existiert [Boh10, S. 23]. Die noätigen Mitarbeiter werden zu ihrer Gruändung aus ihrer urspruänglichen Organisationseinheit herausgenommen und vollstaändig in der neuen Einheit angesiedelt. [Jak15, S. 113] Sowohl disziplinarische als auch fach­liche Weisungsbefugnis liegen damit ausschließlich innerhalb des Projekts, ebenso die vollstaändige Verantwortung fuär den Projekterfolg [KW10, S. 39].

Vorteile dieser Organsiationsform sind die uneingeschraänkte Konzentration auf das Projekt und kurze Kommunikations- und Entscheidungswege, weil die Mitar­beiter vollstäandig dem Projekt zugeordnet sind. So ist effizientes und zielorien­tiertes Arbeiten“ moäglich [Ste14, S. 60-61]. Dadurch ist auch die Identifikation der Teammitglieder mit dem Projekt in der Regel sehr hoch. [Boh10, S. 23] Auf Grund der Trennung zwischen Projekt- und Linienorganisation kommt es zum Beispiel in Bezug auf Ressourcen außerdem weniger zu Konflikten [SOP05, S. 101].

Die dauerhafte Entfernung der Mitarbeiter aus der Linienorganisation kann sich nachteilig auswirken. Gleichzeitig käonnen auch bei der Ruäckfuährung Probleme entstehen. [Boh10, S. 23] Das gilt auch fuär die Uäberfuährung von Projektergebnissen in die Linienorganisation [KW10, S. 39]. Außerdem werden Projektmitarbeiter nicht immer in Vollzeit in einem Projekt benäotigt; die reine PO findet darauf keine Antwort. Die Schaffung einer solchen Organisation ist mit hohem Aufwand verbunden, so dass sie fuär laängerfristige und insbesondere fuär strategisch wichtige Projekte empfohlen wird. [Jak15, S. 113]

Matrixprojektorganisation

Meistens werden Projekte durch eine Matrixprojektorganisation (oder kurz: Matri­xorganisation) in die Gesamtorganisation eingebettet. In diesem Konstrukt berich­tet ein Mitarbeiter sowohl gegenuäber dem Projekt als auch gegenuäber der Linie. [KW10, S. 40] (vgl. Anhang B.2) Die Matrixorganisation (. . . ) soll (also) eine Klammerfunktion darstellen, zwischen der Linienorganisation einerseits und der Projektorganisation anderseits“ [HW17, S. 42], um die Entscheidungs- und Wei­sungsbefugnisse der Projekt- bzw. der Stammorganisation zu kombinieren“ [Ste14, S. 61].

Dass sowohl Projekt- als auch Linienorganisation fuär das Projektergebnis ver­antwortlich sind, kann sich einerseits positiv auswirken. Die Linienorganisation erhaält eine Mitwirkungspflicht und ein konstruktiver Austausch mit der PO wird erforderlich. Es besteht aber die Gefahr, dass es zu Missverstaändnissen und Schuld­zuweisungen kommt. [KW10, S. 41] Bei der Matrixorganisation hingegen ist von Vorteil, dass verglichen mit der reinen PO kaum finanzielle Auswirkungen durch organisatorische Veraänderungen entstehen. [SOP05, S. 104] Aufwaände fuär die Ruäckfuährung der Teammitglieder in ihre Stammorganisation entfallen ebenfalls [Jak15, S. 114]

[...]

---

¹ Scrum = Englisch für Gedränge; gleichzeitig eine Methode aus dem Rugby, das Spiel neu zu starten [Rod15, S.191 ff.]

² Lanzeitstudie zu Erfolgs- und Misserfolgsfaktoren im IT-Projektmanagement

³ Deutsch: Fluss, auch fließende Beherrschung einer Fremdsprache

¹ Vgl. unter anderem [HH11, S. 22], [KW10, S. 15], [KHL+06, S. 5-7], [PR11, S. 22].

² Vgl. unter anderem [Boh10, S. 18-19], [GPM15, S. 16], [Hey80, S. 13], [Jak15, S. 10], [KW10, S. 12-14], [KHL+06, S. 4], [WM11, S. 10]; weitere Begriffsdefinition zum Beispiel in DIN-Norm 69901-5 enthalten.

³ Vgl. unter anderem [Boh10, S. 19], [HH11, S. 24-25], [KW10, S. 21], [Rei09, S. 23].

⁴ Für alle Bestandteile gibt es unter anderem in der jeweils verwendeten Literatur verschiedene Metho­den, Techniken und Hilfsmittel, die jedoch nicht Gegenstand dieser Arbeit sein sollen.

⁵ PRINCE2 steht für Projects in Controlled Environments.

⁶ Der Begriff wurde aus der Literatur übernommen, erscheint jedoch vor dem Hintergrund, dass das ursprüngliche V-Modell schon fast 40 Jahre alt ist, nicht mehr zeitgemaß.

⁷ Den Ausfuhrungen wird das V-Modell XT zu Grunde gelegt, das eine Weiterentwicklung des ur- sprunglichen V-Modell 97 darstellt.

⁸ Use Case = Anwendungsfall aus Sicht des Nutzers

⁹ UML = Unified Modeling Language

¹⁰ In Fachkreisen wird daher auch von einem Rahmenwerk (engl. Framework) gesprochen, vgl. dazu die Definition in The Scrum Guide™ [SS17].

¹¹ Detailliertere Ausführungen zur Kultur folgen in Abschnitt 2.2.2.

¹² Bei der Zieldefinition sollte zum Beispiel die SMART-Regel berucksichtigt werden: S - spezifisch, M - messbar, A - aktionsorientiert oder attraktiv, R - realistisch, T - terminiert [Jak15, S. 58], [Klo09, S. 22], [NS14, S. 262].

¹³ Projektmanagement - Projektmanagementsysteme - Teil 1: Grundlagen, Teil 2: Prozesse, Prozessmo­dell, Teil 3: Methoden, Teil 4: Daten, Datenmodell und Teil 5: Begriffe, https://www.din.de/de/ mitwirken/normenausschuesse/nqsz/normen/wdc-beuth:din21:113428320

¹⁴ In Deutschland vertritt die Gesellschaft fur Projektmanagement e.V. (GPM) die IPMA; vgl. hierzu https://www.gpm-ipma.de/.

¹⁵ PMBOK® steht für Project Management Body of Knowledge

¹⁶ Vgl. unter anderem [Boh10], [Jak15], [MR16], [PR11], [SOP05].

¹⁷ Vgl. unter anderem [GM14], [Han17], [PE14], [Pre15].

¹⁸ https://de.atlassian.com/software/jira

¹⁹ Als wesentliche Schwache eines Projekts wird in diesem Zusammenhang gleichzeitig die mangelnde Berücksichtigung von Umfeldbedingungen auf Grund einer zu strikten Einhaltung von Vorgaben ge­nannt, die zum Beispiel auf eingesetzte Vorgehensmodelle (vgl. Abschnitt 2.1.1) zuruckzufuhren sind. [HK15, S. 20-22]

²⁰ Unter einer Linienorganisation wird der hierarchische Aufbau einer Organisation verstanden.

²¹ Vgl. unter anderem [Boh10, S. 22-24], [Hey80, S. 17], [Jak15, S. 112-117], [Klo09, S. 222-225], [NS14, 257-260], [Ste14, S. 17]; Mischformen sind ebenfalls vorhanden, werden aus Vereinfachungsgrunden jedoch nicht naher beschrieben.