Projektmanagement - klassisch, agil, lean und systemisch

Inhaltsverzeichnis

Bilderverzeichnis

Tabellenverzeichnis

Abkürzungs- und Akronymverzeichnis

1. Zentrale Problemstellung und Vorgehen
1.1 Motivation
1.2 Ziele und Forschungsfragen
1.3 Vorgehensweise

2. Projektmanagement – klassisch
2.1 Projekt
2.2 Management
2.3 Klassisches Projektmanagement
2.4 Weltbild – klassisch
2.5 Das Wasserfallmodell als klassischer Vertreter

3. Projektmanagement – agil und lean
3.1 Agilität
3.2 Agiles Manifest
3.3 Lean
3.4 Weltbild – agil und lean
3.5 Kanban in der IT
3.5.1 Grundlagen
3.5.2 Visualisierung des Workflows
3.5.3 WiP-Begrenzung
3.5.4 Pull statt Push
3.5.5 Kaizen
3.5.6 Workflow managen
3.5.7 Meetings und Rhythmus
3.5.8 Kritische Betrachtung

4. Systemtheorie
4.1 Grundlagen der Systemtheorie
4.2 Systembegriff
4.3 Soziale Systeme und Kommunikation
4.4 Kritische Betrachtung

5. Projektmanagement in Kooperation – Agil und Systemisch
5.1 Grundlagen
5.2 Werte
5.3 Prinzipien
5.4 Weltbild – Agil und Systemisch
5.5 Repository
5.5.1 Rollen
5.5.2 Vorgehen und Artefakte
5.5.3 Praktiken
5.6 Kritische Betrachtung

6. Erweiterung von PiK-AS
6.1 Eignung von Kanban
6.2 Vorgehensweise der Erweiterung
6.3 Werte
6.4 Prinzipien
6.5 Weltbild – Agil, Lean und Systemisch
6.6 Repository
6.6.1 Vorgehen und Artefakte
6.6.2 Rollen
6.6.3 Praktiken
6.7 Kritische Betrachtung

7. Validierung
7.1 Grundlagen und Vorgehen
7.2 Auswahl der Interviewpartner
7.3 Ergebnisse

8. Fazit und Ausblick

9. Anhang
9.1 Anhang A: PiK-AS Prinzipien
9.2 Anhang B: PiK-AS Praktiken
9.3 Anhang C: PiK-AS Validierung
9.4 Anhang D: Interviewvorbemerkung
9.5 Anhang F: Interviews mit den Experten
9.5.1 Interview mit einem wissenschaftlichen Mitarbeiter
9.5.2 Interview mit zwei Unternehmensberatern

Literaturverzeichnis

Bilderverzeichnis

Abbildung 1: Ergebnisse der Chaos Reports von 1994 bis 2009

Abbildung 2: Ergebnisse der oose Studie

Abbildung 3: Das magische Dreieck

Abbildung 4: Das Wasserfallmodell

Abbildung 5: Ein selbstregulierender Kanbanregelkreis

Abbildung 6: Ein einfaches Kanbanboard

Abbildung 7: Gestaltungsmöglichkeiten eines Kanbanboards

Abbildung 8: Ein Kanbanticket

Abbildung 9: Ein legitimer Pull

Abbildung 10: Ein illegitimer Pull

Abbildung 11: Ein Cumulative Flow Diagram

Abbildung 12: Systeme in der Systemtheorie – Überblick

Abbildung 13: Soziale Systeme – Überblick

Abbildung 14: PiK-AS – Überblick

Abbildung 15: PiK-AS Vorgehen

Abbildung 16: PiK-AS+K – Überblick

Abbildung 17: PiK-AS+K Vorgehen

Tabellenverzeichnis

Tabelle 1: Zusammenfassung der definierten Begriffe des Projektmanagements

Tabelle 2: Werte des agilen Manifests

Tabelle 3: Prinzipien des agilen Manifests

Tabelle 4: Weltbilder im Vergleich – klassisch, agil und lean

Tabelle 5: PiK-AS Prinzipien

Tabelle 6: Weltbilder im Vergleich – klassisch, agil und lean, systemisch

Tabelle 7: PiK -AS Praktiken

Tabelle 8: Fragenkatalog nach Trepper zur Methodenbasisfindung

Tabelle 9: Fragenkatalog Ergebnisse

Tabelle 10: Wertesystem von PiK-AS+K

Tabelle 11: PiK-AS+K Prinzipien

Tabelle 12: Rollen in PiK-AS+K

Tabelle 13: PiK-AS+K Praktiken

Tabelle 14: PiK-AS+K Ergebnis

Tabelle 15: Interviewleitfaden zur Validierung von PiK-AS+K

Abkürzungs- und Akronymverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Zentrale Problemstellung und Vorgehen

Dieses Kapitel beschreibt die Motivation, Ziele, Forschungsfragen sowie das Vorgehen die­ser Ausarbeitung.

1.1 Motivation

Projekte und deren Management sind aus dem heutigen wirtschaftlichen Alltag nicht mehr wegzudenken. Doch die Bedeutung und die Komplexität des Projektmanagements, insbesondere des IT-Projektmanagements nimmt stetig zu (Gassmann 2006, S. 3). Die höher zugesprochene Bedeutung, ist durch die wachsende Komplexität der Aufgaben in Unternehmen zu begründen (Leitner 2011, S. 18). Um dieser Komplexität entgegen zu wirken, herrschen in der Literatur und Praxis unterschiedliche Ansätze. Neben dem klassischen Projektmanagement, gibt es das in letzter Zeit verstärkt diskutierte systemische und das agile Projektmanagement (Trepper 2010, S. 2).

Der in regelmäßigen Abständen erscheinende CHAOS Report der Standish Group untersucht die Erfolgsquote von Softwareentwicklungsprojekten. Im Jahr 1994 waren 31 % der Projekte gescheitert und 53 % verspätet, oder mit einer Budgetüberschreitung verbunden (Standish Group 1994). 2009 lagen die Zahlen bei 24 % für gescheiterte Projekte und 44 % für teilweise erfolgreiche Projekte. Die Summe an erfolgreichen Projekten lag bei 16 % (1994), 28 % (2000) und 32 % (2009) (Standish Group 1994 / 2001 / 2009). Abbildung 1 zeigt die Ergebnisse des CHAOS Reports noch einmal grafisch. Die Studien zeigen, dass zwischen 1994 und 2009, die Summe der gescheiterten und nur teilweise erfolgreichen Projekte stetig gesunken ist. Der CHAOS Report wird in der Literatur kontrovers diskutiert, sodass sich Zweifel gegenüber der Methodik und den Ergebnissen nicht ausräumen lassen und somit kritisch zu hinterfragen sind (Eveleens und Verhoef 2010, S. 30-36; Jørgensen und Moløkken 2006, S. 297-301). Dennoch kann festgehalten werden, dass IT-Projekte heute noch signifikant häufig scheitern.

Bedenkt man, dass die ersten agilen Methoden wie eXtreme Programming oder Crystal im Jahr 2003 veröffentlicht wurden, so liegt der Verdacht nahe, dass die Reduzierung der Summe an überschrittenen Projekten zwischen 2004 und 2009, sowie die Steigerung der Erfolgsquote durch agile Methoden bewirkt wurde. Diese These wird durch die oose Studie (2008), welche in Kooperation mit dem Project Management Institute (PMI) und der Deutschen Gesellschaft für Projektmanagement (GPM) 212 Projektleiter nach den Erfolg ihrer Projekte befragt hat, untermauert. Die Studie zeigt, dass agile Projektmethoden zu 59,2 %, währenddessen klassische Projektmethoden zu 40,8 %, erfolgreich sind. Abbildung 2 stellt die Ergebnisse der oose Studie noch einmal grafisch dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Ergebnisse der Chaos Reports von 1994 bis 2009

Quelle: Eigene Darstellung in Anlehnung an Standish Group (1994, 1996, 1998, 2000, 2004, 2006, 2009).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Ergebnisse der oose Studie

Quelle: Eigene Darstellung in Anlehnung an oose (2008).

Projekterfolgskriterien lassen sich nach Bundschuh (2003, S. 192) in hard factors und soft factors einteilen. So differenziert er hard factors als materielle Dinge, welche quantifizierbar sind und soft factors als bedingt quantifizierbare, menschliche Erlebnisse. So stellt er weiterhin fest, „daß mehr als die Hälfte der Projekterfolgskriterien soft factors sind, und nur knapp die Hälfte hard factors“ (Bundschuh 2003, S. 192). Eines der Kernprobleme des klassischen Projektmanagements sind nicht berücksichtigte soft factors wie z. B. Kommunikation und Vertrauen (Halamzie 2012, S. 10-11, 21).

So stellt auch die Studie der Gpm (2008) fest, dass vor allem Kommunikation, unklare Anforderungen und die Qualifikation der Mitarbeiter am häufigsten für den Erfolg, bzw. Misserfolg der ausgewählten Projekte ausschlaggebend sind. Soft factors werden in derzeitigen Projektmanagementmethoden nur unzureichend, bzw. nur teilweise unterstützt (Huber 2011, S. 210). Um dieses Defizit zu beheben, veröffentlichte Trepper, die agil-systemische Methode PiK-AS, welche die Grundlage und den Schwerpunkt dieser Arbeit bildet (2010, S. 3-5; Drechsler, Kalvelage, Trepper 2010, S. 129-130).

1.2 Ziele und Forschungsfragen

PiK-AS stellt den bis dato ersten explizit agil-systemischen Ansatz zur Softwareentwicklung dar (Trepper 2010, S. 3-4). Bei der Auswahl der Basis für PiK-AS wurden sieben Methoden untersucht, sodass die Potenziale anderer Methoden nicht in die Untersuchung einfließen konnten (Trepper 2010, S. 126). Trepper (2010, S. 130-131) weist explizit auf den Umstand hin, dass durch eine andere Selektion von Methoden zur Basisfindung von PiK-AS, eine abweichende Methode hätte resultieren können. Bei der Entstehung der Methode wurde der Fokus primär auf die agile Methoden Scrum^[1] und eXtreme Programming^[2] gelegt und aus einer systemischen Perspektive auf das Projektmanagement betrachtet (Trepper 2010, S. 130-131). Kanban stellt eine alternative, agil-leane Methode zu Scrum dar, welche nach Halamzie (2012, S. 42), eine Methode mit einem gleichzusetzenden Agilitätsgrad wie Scrum ist. Weiterhin stellte er heraus, dass das entscheidende Kriterium zur Auswahl zwischen den beiden Methoden, die Zielsetzung des Projektes ist (Halamzie 2012, S. 42). Dadurch stellt sich die Frage,

ob bei der Weiterentwicklung von PiK-AS die Berücksichtigung von leanen Faktoren aus Kanban, einen Mehrwert für das Projektmanagement liefert. Aus diesem Umstand ergeben sich folgende Forschungsfragen, welche als Ziele dieser Arbeit definiert werden:

1. Ist Kanban ein geeigneter Kandidat zur Erweiterung von PiK-AS?
2. Kann eine, um leane Faktoren aus Kanban erweiterte PiK-AS Methode, einen Mehrwert für das Projektmanagement erzeugen?

Diese Fragen gilt es im Rahmen dieser Ausarbeitung zu bestätigen oder zu widerlegen. Das Erkenntnisziel dieser Arbeit besteht aus der Erstellung einer, um leane Faktoren erweiterten, PiK-AS Methode.

1.3 Vorgehensweise

Um eine Grundlage für das Verständnis der zugrunde liegenden Thematik des agil-systemischen Projektmanagements zu schaffen, werden in den Kapiteln 2 und 3, das klassische und das agil-leane Projektmanagement voneinander abgegrenzt. Beide Kapitel definieren zunächst die zentralen Begriffe der jeweiligen Strömung, um darauf aufbauend das zugehörige Weltbild zu skizzieren. Im Anschluss wird jeweils ein exemplarisches Vorgehensmodell aus der Softwareentwicklung vorgestellt, um den generellen Ablauf des entsprechenden Projektmanagementansatzes aufzuzeigen. Der Fokus des dritten Kapitels liegt auf Kanban, aufgrund dessen zentralen Rolle bei der Erweiterung von PiK-AS. Kapitel 4 legt mit einer Ausarbeitung der Systemtheorie nach Luhmann, den Grundstein zum Verständnis von PiK-AS. So wird zunächst auf den Systembegriff in der Systemtheorie eingegangen, um darauf aufbauend soziale Systeme samt dem korrespondierenden Kommunikationsbegriff näher zu betrachten. Weiterhin wird die Systemtheorie als theoretische Fundierung von PiK-AS noch einmal kritisch betrachtet, um insbesondere deren Annahmen und Prämissen aufzudecken. Kapitel 5 widmet sich der agil-systemischen Methode PiK-AS und beschreibt deren Bestandteile, um diese in Kapitel 6 aufzugreifen und gezielt um leane Faktoren aus Kanban zu erweitern. Zudem wird zur Beantwortung der ersten Forschungsfrage in Kapitel 6, Kanban als Erweiterungsgrundlage verifiziert. Die Erweiterung in Kapitel 6 baut auf die gesammelten Erkenntnisse im Verlauf der Arbeit auf. In Kapitel 7 wird zur Beantwortung der zweiten Forschungsfrage die erweiterte Methode mit Hilfe von Experteninterviews verifiziert. Dabei wird das Vorgehen der Verifikation skizziert und die Ergebnisse der Evaluation vorgestellt. In einem abschließenden Fazit werden in Kapitel 8 die Erkenntnisse dieser Arbeit zusammengefasst und ein Ausblick auf weitere Forschungsthemen rund um die erweiterte PiK-AS Methode gegeben.

2. Projektmanagement – klassisch

In diesem Kapitel wird das klassische Projektmanagement mit dessen zentralen Begriffen des Projekts, Managements sowie Projektmanagements beschrieben. Anschließend wird die Beschreibung am Beispiel des Wasserfallmodells in der Softwareentwicklung, welches eines der bekanntesten und verbreitetsten Entwicklungsmodelle im Sinne des klassischen Projektmanagements darstellt, erläutert (Chughtai 2002, S. 30). Zudem wird das Weltbild des klassischen Projektmanagements näher untersucht und kritisch hinterfragt.

2.1 Projekt

Dieses Kapitel definiert den dieser Arbeit zugrunde liegenden Begriff eines Projekts.

In der Literatur existieren unterschiedliche Definitionen um den Begriff des Projekts gegenüber der allgemeinen Arbeitsweise in einer Linienorganisation abzugrenzen. So definiert Küsters (1998, S. 3) sowie Aichele (2006, S. 30) ein Projekt wie folgt:

Ein Projekt wird als ein Vorhaben definiert,

- dessen Ablauf zumindest weitgehend einmalig ist,
- dessen Struktur eine bestimmte Komplexität aufweist,
- dessen festgelegte Zielsetzung in vorgegebener Zeit und mit den gegebenen Mitteln zu erreichen ist.

Eines der verbreitetsten Definitionen ist laut Pinkenburg (1980, S. 100) die Din Norm 69601, welche auch von der Gesellschaft für Informatik benutzt wird:

Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in seiner Gesamtheit gekennzeichnet ist, z. B.

- Zielvorgabe,
- zeitliche, finanzielle, personelle und andere Begrenzungen,
- Abgrenzung gegenüber anderen Vorhaben und
- projektspezifische Organisation.

Eine weitere Definition liefern WIECZORREK und MERTENS, (2007, S. 7-9) nach der ein Projekt:

- einer exakten Aufgabendefinition,
- der Abgrenzbarkeit von operativen Unternehmensaufgaben,
- einem eindeutigen Start- und Endtermin,
- Einzigartigkeit, in dem Sinne, dass es ein solches Projekt noch nicht gegeben hat,
- der Konkurrenz von Projekten um knappe Ressourcen,
- der existenziellen Wichtigkeit für eine Unternehmung und
- einem hohen Risiko.

Betrachtet man diese Definitionen, findet man größtenteils Übereinstimmungen, jedoch mit feinen Unterschieden. Küsters bezeichnet ein Projekt als einen „weitgehend einmaligen“ Vorgang, während die Definitionen der Gesellschaft für Informatik sowie Wiezorreks und Mertens, die Einmaligkeit von Projekten betonen. Die Din Norm ist an dieser Stelle konkreter und zählt die wesentlichen Ressourcen auf: „zeitliche, finanzielle, personelle und andere Begrenzungen“ (DIN 69601 nach Pinkenburg 1980, S. 100). Wiezorreks und Mertens Definition gehen einen Schritt weiter und erweitern den Projektbegriff um drei weitere Elemente. So ist von einer „Konkurrenz von Projekten“ sowie von „knappen Ressourcen“ die Rede, während in der Definition von Küsters sich keine detaillierte Formulierung findet, welche auf die Knappheit von Ressourcen eingeht (Wieczorrek und Mertens 2007, S. 7-9). Küsters Definition ist in diesem Punkt allgemein gehalten (Küsters 2003, S. 3). Zudem kommen einzig in der Definition von Wiezorrek und Mertens die Elemente der „existenziellen Wichtigkeit“ und des „hohen Risikos“ vor. Aus diesen Punkten wird die Definition eines Projekts im Rahmen dieser Ausarbeitung wie folgt definiert:

Ein Projekt ist ein Vorhaben, welches einmalig ist und einen festen Rahmen bezüglich vorhandener Ressourcen besitzt, dessen Start und Ende zeitlich klar definiert und von operativen Unternehmensaufgaben klar abgegrenzt ist. Zudem ist es von großer (wirtschaftlicher) Bedeutung für das Unternehmen.

Diese Definition richtet sich an den Gemeinsamkeiten der drei zuvor genannten Definitionen, lässt jedoch einen gewissen Interpretationsspielraum bezüglich der Ressourcennutzung. Zudem wurde die Wichtigkeit für das Unternehmen, in Anlehnung an der Definition von Wiezorrek und Mertens hervorgehoben.

2.2 Management

In diesem Kapitel wird der Begriff des Managements für diese Arbeit definiert. Die Managementliteratur kennt zwei unterschiedliche Perspektiven auf das Management (Schreyögg 2007, S. 7). Das Management aus der institutionellen Perspektive legt den Fokus auf Führungspersonen bzw. eine Gruppe von Führungspersonen in einer Organisation, welche Weisungsbefugnisse gegenüber anderen Personen in der Organisation besitzt (Schreyögg 2007, S. 7). Ulrich und Fluri (1980, S. 36) definieren die institutionelle Perspektive wie folgt:

„Management ist die Leitung soziotechnischer Systeme in personen- und sachbezogener Hinsicht mit Hilfe von professionellen Methoden. […] in der personenbezogenen Dimension [geht es] um den richtigen Umgang mit allen Menschen, auf deren Kooperation das Management zur Aufgabenerfüllung angewiesen ist.“

Währenddessen das Management aus der funktionalen Perspektive den Fokus auf die Aufgaben zur Steuerung einer Organisation legt und explizit nicht auf die Position oder Personen, die diese Aufgabe ausführen (Schreyögg 2007, S. 7). Die klassische Managementlehre unterteilt die Aufgaben (funktionale Perspektive) eines Managements in einen Komplex von Entscheidungen über die Prozesse: Planung, Steuerung, Kontrolle, Führung, Personal und Organisation eines Unternehmens (Hentze et al. 2001, S. 191; Sjurts 2010, S. 360). Hentze et al. (2001, S. 191) heben bei ihrer Definition der Managementaufgaben explizit die zentrale Bedeutung der Planung hervor, welche über den restlichen Managementaufgaben steht und diese steuert. In Anlehnung an Hentze et al. (2001, S. 191) wird für diese Ausarbeitung Planung im klassischen (Projekt-) Management wie folgt definiert:

Planung ist das systematische antizipieren zukünftiger Handlungen. Dabei werden Ziele dieser Handlungen bestimmt, um eine optimale Entscheidungsfindung über den zugrunde liegenden Gegenstand der Planung zu erreichen.

Unter Rückgriff auf diese Planungsdefinition, sowie in Anlehnung an Schreyöggs und Kochs (2007, S. 8), sowie Sjurts (2010, S. 360) funktionaler als auch Ulrichs und Fluris institutioneller Definition, wird der Begriff des Managements im Rahmen dieser Ausarbeitung wie folgt definiert:

Management ist ein Komplex von Steuerungsaufgaben zur Leistungserstellung in einer Organisation. Zentraler Bestandteil des Managements ist die Planung über die Managementprozesse: Steuerung, Kontrolle, Führung und Organisation. Dabei leitet und koordiniert das Management die in dem sozio-ökonomischen System der Organisation beteiligten Menschen, um die gesetzten Ziele der Managementprozesse zu erreichen.

Diese Definition betrachtet den Begriff aus den beiden vorherrschenden Perspektiven und bietet in Synthese mit der Projektdefinition eine Grundlage zur Schaffung des Projektmanagementverständnisses der nächsten Kapitel.

2.3 Klassisches Projektmanagement

Dieses Kapitel formuliert den in dieser Arbeit verwendeten Projektmanagementbegriff. Dabei wird explizit auf die Definitionen des Projekts (vgl. Kap. 2.1) und des Managements (vgl. Kap. 2.2) zurückgegriffen. Die Din (6901 nach Zell 2008, S. 7) definiert das Projektmanagement wie folgt:

„Die Gesamtheit der Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projekts.“

Eine weitere Definition liefert Rinza (1998, S. 4):

„Projektmanagement bedeutet also die Leitung – Leitung hier insbesondere verstanden als Planung, Überwachung und Steuerung – eines Projektes sowie die das Projekt leitende Institution.“

Beide Definitionen berücksichtigen die institutionelle Perspektive des Managements (vgl. Kap. 2.2) unzureichend. So spricht die Din ausschließlich von „Führungsaufgaben“ (Din 6901 nach Zell 2008, S. 7), ohne die projektbeteiligten Menschen und deren Kooperation zu benennen (vgl. Kap. 2.2). Zudem heben beide Definitionen nicht die konkurrierenden Faktoren zur Zielerreichung des Projektmanagements eindeutig hervor. Die in Wechselwirkung stehenden Faktoren Zeit, Kosten und Qualität sind in der Literatur auch unter dem Namen magisches Dreieck zu finden (vgl. Abbildung 3). So ist nach Kessler und Winkelhofer (2004, S. 55-56) ein Faktor immer von den anderen beiden abhängig, d. h. um Termintreue zu gewährleisten, muss entweder die Qualität vermindert werden, oder die Kosten steigen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Das magische Dreieck

Quelle: Eigene Darstellung in Anlehnung an Kessler und Winkelhofer (2004, S. 55).

Unter Berücksichtigung der in Kapitel 2.1 und 2.2 ausgearbeiteten Begriffe des Projekts und des Managements, sowie des in diesem Kapitel näher eingegrenzten Projektmanagementbegriffs, wird Projektmanagement im Rahmen dieser Arbeit wie folgt definiert:

Projektmanagement bedeutet die Planung der Gesamtheit an Managementprozessen, unter Berücksichtigung der Koordination und Führung der projektbeteiligten Personen und deren Kooperation untereinander zur Abwicklung eines Projektes.

Tabelle 1 fasst die aus dieser Arbeit resultierenden Definitionen des klassischen Projektmanagements zusammen.

Tabelle 1: Zusammenfassung der definierten Begriffe des Projektmanagements

Abbildung in dieser Leseprobe nicht enthalten

2.4 Weltbild – klassisch

In diesem Kapitel wird das Weltbild des klassischen Projektmanagements gezeichnet.

Wie in den Kapiteln 2.2 und 2.3 ausgearbeitet, stellt Planung das zentrale Element des klassischen Projektmanagements dar, welches hier feingranularer betrachtet wird, um Prämissen über den Planungsprozess und dem zugrunde liegenden Weltbild aufzeigen.

Die Vorgehensweise im klassischen Projektmanagement lehnt sich eng an das tayloristische Arbeitsverständnis an, in dem Arbeitsschritte nach einem zuvor wohl definierten und erstellten Plan ablaufen (Koch 2008, S. 5). Bei einem solchen Prozess werden linear-kausale Zusammenhänge über Projektelemente bzw. deren Gesetzmäßigkeiten angenommen (Poczyne und Hinz 2011, S. 75; Koch 2007, S. 5). Lineare Kausalität bedeutet in diesem Zusammenhang, dass ausgehend von gleichen Anfangsbedingungen, die gleichen Wirkungen zu erwarten sind (Hanzl 1995, S. 73). Solche Projektelemente könnten Mitarbeiter, Termine, Budget, Ziele, Probleme, Problemlösungen oder auch die Umwelt an sich sein.

Planung beinhaltet das Vorwegnehmen von zukünftigen Entscheidungen und Handlun­gen (vgl. Kap. 2.2), welches Kropfberger et al. (2000, S. 18) auch als vorausschau­end, bzw. Vorhersage bezeichnen. Bei der Planung werden implizit Annahmen getroffen und mögliche zukünftige Szenarien geistig abgelaufen, um auf Basis dieser Abläufe, einen möglichen Handlungsstrang zu verfolgen (Kropfberger et al. 2000, S. 17-20; Maurer 1995, S. 46). Beste et al. (1975, S. 43-44) definieren die Planung als Vorausschau. Dabei wird eine erhebliche bis vollständige Bekanntheit über die Gesamtheit der Projektelemente und deren korrespondierenden Gesetzmäßigkeiten angenommen (Kropfberger et al., 2000, S. 14, 18). Aus diesen Gesetzmäßigkeiten und der Planung selber, wird durch Deduktion auf die zukünftige Handlung geschlossen. Eine solche Denkweise wird in der Literatur auch Determinismus^[3] genannt, bzw. einem mechanistischen Weltbild^[4] zugeordnet.

2.5 Das Wasserfallmodell als klassischer Vertreter

Dieses Kapitel zeigt am Beispiel des Wasserfallmodells den generellen Ablauf einer klassischen Softwareentwicklung. Das Wasserfallmodell ist das älteste und ein weitverbreitetes Vorgehensmodell in der Softwareentwicklung (Chughtai et al. 2002, S. 30). Es unterteilt die Entwicklung einer Software in Phasen^[5] wie Anforderungsanalyse, Softwaredesign, Implementierung, Test und Wartung (vgl. Abbildung 4) (Chughtai et al. 2002, S. 30). Diese Phasen werden sequenziell und einmalig durchlaufen, jedoch mit der Möglichkeit eines Rückschritts zur vorherigen Phase.

Das Wasserfallmodell ist von dem des klassischen Projektmanagements zugrunde liegenden Begriff der Planung geprägt, sodass es die Entwicklung von Software zu einem Gegenstand der Planbarkeit, der Antizipation zukünftiger Ereignisse, sowie klaren Zielvorgaben transformiert (vgl. Kap. 2.2). So gibt es eine ganze Reihe von Problemen, welche bei einem sequenziellen, linearen und starren Ablauf (Wasserfallmodell) zu signifikant hohen Überschreitungen der Rahmenbedingungen, d. h. den Zeit- und Budgetvorgaben, führen (Szalvay 2004, S. 6). So stellt Halamzie (2012, S. 10-11) dar, dass die Gründe für das häufige Scheitern von klassischen IT-Projekten, dem Vorgehen an sich inhärent sind. Software in Anforderungen präzise zu explizieren und zu kommunizieren fällt Anwendern außerhalb der Informatikdomäne schwer. Die kommunizierten Anforderungen und Ziele entsprechen nicht denen, welche der Auftraggeber eigentlich im Sinn hatte (Munz und Soergel 2007, S. 71-73). Diese Problematik liegt vor allem in dem einmaligen Durchlauf der Anforderungsanalyse und dem Mangel eines Feedbacks während der Entwicklung (Munz und Soergel 2007, S. 73).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das Wasserfallmodell

Quelle: Eigene Darstellung in Anlehnung an Gran (2008, S. 17).

3. Projektmanagement – agil und lean

In diesem Kapitel wird das agile Projektmanagement näher betrachtet. Agiles Projektmanagement wird primär in der Softwareentwicklung angewendet und ist im Rahmen dieser Arbeit als solches zu betrachten. In diesem Kapitel wird in einem ersten Schritt der Begriff Agilität näher eingegrenzt und für den Rahmen dieser Arbeit definiert. In einem zweiten Schritt werden unter Rückgriff auf das Agile Manifest, die Werte und Prinzipien hinter agilen Methoden vorgestellt. Zudem wird auf leane Prinzipien eingegangen, um in einem letzten Schritt Kanban als agile-leane Methode zu erläutern.

3.1 Agilität

Um ein Verständnis für agiles Projektmanagement und dessen Abgrenzung sowie Unterschied zum klassischen Projektmanagement zu bekommen, wird in diesem Kapitel zunächst der Begriff der Agilität näher eingegrenzt und für diese Ausarbeitung definiert. Agilität wird von Highsmith (2002, S. 29) wie folgt definiert:

“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.”

Eine weitere bekannte Definition von Agilität ist die von Goldman et al. (1995 S. 42), welche in der Literatur auch häufig Cockburn^[6] (2002) zugesprochen wird:

„Agility is dynamic, context specific, aggressively change-embracing and growth-oriented. It is not about improving efficiency, cutting costs or battening down the business hatches to ride out fearsome competitive ‘storms.’ It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share and customers in the very center of the competitive storms many companies now fear.“

Holsapple und Li (2008, S. 6) definieren Agilität wie folgt:

“Agility is the result of integrating alertness to changes (recognizing opportunities/challenges) – both internal and environmental – with a capability to use resources in responding (proactive/reactive) to such changes, all in a timely, flexible, affordable, relevant manner.”

Bei der Betrachtung der Definitionen wird ersichtlich, wie diffus der Begriff der Agilität in der Softwareentwicklung ist. Eines der zentralen Elemente aller Definitionen ist die Fähigkeit auf Änderungen zu reagieren. Goldman et al. (1995 S. 42) gehen noch einen Schritt weiter und bezeichnen das Verhalten auf Änderungen als “change embracing”. Weiterhin betonen Goldman et al. (1995 S. 42) sowie Highsmith (2002, S. 29) explizit die Profitorientierung von Agilität in einer dynamischen und emergent-chaotischen Welt.

Dagegen differenzieren Holsapple und Li (2008, S. 6) die Fähigkeit zu reagieren in einen proaktiven Prozess (Agieren) und in die reaktive Fähigkeit, auf Änderungen spontan und ohne vorherige Planung zu reagieren. Diese Differenzierung zwischen einen proaktiven und reaktiven Agilitätsbegriffs findet sich in der Agilen Literatur häufig wieder (Naylor et. al. 1999, S. 107-118; Stratton und Warburton 2003, S. 184-188).

Zudem besitzt Agilität weitere Eigenschaften, die durch die drei angeführten Definitionen nicht abgedeckt werden. Agilität bedeutet nach Gunasekaran und Yusuf (2002, S. 1357) auch „new ways of running business“ sowie „casting off old ways of doing things“, wodurch die Innovationskraft von Agilität betont wird. Diese Eigenschaft wird auch von Christopher und Towill (2000, S. 206-207) untermauert, indem sie Agilität als „opportunity exploitation“ bezeichnen. Breu et al. (2001, S. 21-25) erweitern diese Reaktionseigenschaft von Agilität durch die Betonung der Schnelligkeit von agilen Methoden. Zusammenfassend wird Agilität im Rahmen dieser Arbeit wie folgt definiert:

Agilität ist die Fähigkeit, in einer dynamischen, emergent-chaotischen Umgebung schnell zu Agieren und Reagieren. Dabei werden innovative und neue Wege zur Lösungsfindung genutzt, um einen Mehrwert für den Kunden, sowie sich für selbst zu generieren.

3.2 Agiles Manifest

In diesem Kapitel wird das Agile Manifest erläutert. Das Agile Manifest wurde 2001 von führenden Vertretern und Autoren aus dem Umfeld des agilen Projektmanagements verfasst. Ziel des agilen Manifests ist es, einen Handlungsleitfaden für agile Methoden, mit Hilfe von vier Werten und zwölf Prinzipien, zur Verfügung zu stellen (Götzenauer 2009, S. 26). Das Agile Manifest ist ein Werk ohne konkrete wissenschaftliche Fundierung und versteht sich als eine Sammlung von Best Practices, welche primär auf den Erfahrungen der Autoren basiert (Götzenauer 2009, S. 26-27). Die Werte des agilen Manifests sind mit Gegenstücken sowie einer Gewichtung verbunden (vgl. Tabelle 2). Die Werte lassen einen gewissen Raum an Interpretation zu, wodurch das Agile Manifest nur als grobe Handlungsrichtung ohne konkrete Handlungsanweisung erscheint, welches durch folgendes Zitat deutlich wird:

„Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“ (agilemanifesto.org).

Tabelle 2: Werte des agilen Manifests

Quelle: Eigene Darstellung in Anlehnung an agilemanifesto.org.

Abbildung in dieser Leseprobe nicht enthalten

Die Werte Individuen und Interaktionen heben den Fokus gegenüber den Werten Prozesse und Werkzeuge zum einen auf die projektbeteiligten Menschen und zum anderen auf die Kommunikation zwischen diesen, sodass Individuen und Interaktionen als zentrale Erfolgsfaktoren für IT-Projekte gelten. Durch diesen Fokus werden vor allem zwischenmenschliche Dinge wie Motivation und Kommunikation zwischen den Projektteilnehmern wichtiger, als festgelegte Prozesse wie z. B. Organisationshierarchien (Wieczorrek und Mertens 2007, S. 110; Munz und Soergel 2007, S. 82). Bleek und Wolf (2008, S. 13-14) stellen zudem explizit die Planung als Gegenstück der Interaktion gegenüber. Weiterhin ist nach Beck (2004, S. 29) eine mangelnde oder schlechte Kommunikation die Grundursache der meisten Probleme in der Softwareentwicklung. Das Agile Manifest adressiert das Problem der mangelnden Kommunikation und versucht dieses zu beheben (Beck 2004, S. 29).

Solange die essenziellen Anforderungen an eine Dokumentation erfüllt sind, wird der Fokus primär auf eine funktionierende Software anstatt auf eine umfassende Dokumentation gesetzt (Munz und Soergel 2007, S. 82).

Der Leitsatz Zusammenarbeit mit dem Kunden setzt vor allem auf eine enge Kommunikation mit dem Kunden. Dadurch können Anforderungen und Wünsche des Kunden aufgrund des direkten Feedbacks genauer als bei einer schriftlichen Ausarbeitung erfasst werden (Wieczorrek und Mertens 2007, S. 111). Das Gegenstück dazu ist die Vertragsverhandlung, welche eine klare und eindeutige Anforderungsdefinition zu Beginn des Projekts voraussetzt. Diese Prämisse kann in der Softwareentwicklung selten angenommen werden (Kleuker 2011, S. 43). Werden die Inhalte der Anforderungen unzureichend oder unklar definiert und kommuniziert, können daraus (rechtliche) Streitsituationen zwischen den Vertragspartnern entstehen (Sutherland 2011, S. 14; Parnas und Clements 1996, S. 251-252).

Der Leitsatz Reagieren auf Veränderung beinhaltet Parallelen zum definierten Agilitätsbegriff, da die Reaktion und die Flexibilität in einer chaotischen Umwelt explizit betont werden (vgl. Kap. 3.1). Weiterhin berücksichtigt Reagieren implizit auch das Agieren, d. h. proaktiv Änderungen zu antizipieren und in den Planungsprozess mit einzubinden (vgl. Kap. 3.1). In Kapitel 2.4 wurde ersichtlich, dass bei einem linear-kausalen, deterministischen Weltbild davon ausgegangen wird, dass bei der Planung zukünftige Ereignisse antizipiert werden können. Der Leitsatz Reagieren auf Veränderung steht explizit als Gegenstück zum Befolgen eines festen Plans (Wieczorrek und Mertens 2007, S. 111-113). Neben diesen Werten existieren zwölf weitere Prinzipien, welche die agilen Werte konkretisieren und erweitern (vgl. Tabelle 3). Nach Biberger (2010, S. 83) betonen die agilen Prinzipien insbesondere die Fähigkeit, auf (unvorhergesehene) Änderungen reagieren zu können. Aus einer agilen Perspektive betrachtet, bieten diese Änderungen eine Innovationskraft, welche man sich aneignen kann (vgl. Kap. 3.1). Zudem zieht sich die Kommunikation als roter Faden durch das Agile Manifest, welche maßgebend die Kundenzufriedenheit fördert und damit auch entscheidend zum Projekterfolg beiträgt (Halamzie 2012, S. 21-23).

Weiterhin stellen die agilen Prinzipien die Wichtigkeit von Reflexionsphasen heraus. Die Reflexionsphase soll zu der Erkenntnis führen, welche Projektelemente Verbesserungspotenzial bieten und welche sich bewährt haben (Pries und Quigley 2011, S. 43). Durch diesen Prozess gewinnen die Mitarbeiter mit dem Projektfortschritt an Erfahrung, lernen diese für zukünftige Projekte zielführend einzusetzen und leisten somit einen entscheidenden Beitrag zur Prozess- und Qualitätsverbesserung (Cohn 2010, S. 32).

Tabelle 3: Prinzipien des agilen Manifests

Quelle: Eigene Darstellung in Anlehnung an agilemanifesto.org

Abbildung in dieser Leseprobe nicht enthalten

3.3 Lean

In diesem Kapitel wird der Begriff Lean im (Software-)Projektmanagement erläutert. Der Begründer von Lean ist der Japaner Tai-Chi Ōno, welcher als Produktionsleiter bei Toyota in der Mitte des 20. Jahrhunderts einen Weg suchte, sich gegen die amerikanische Massenproduktion in der Automobilindustrie zu wehren (Glaser et al. 1992, S. 256). Japan hatte im Gegensatz zu den USA, wenig bebaubare Flächen und eine hohe Rohstoffknappheit (Wöhe und Dörring 2003, S. 450). Der Fokus des Lean-Gedanken lässt sich zum einen positiv konnotiert verwenden, indem Werte für den Kunden geschaffen werden und zum anderen negativ verwenden, indem Verschwendung vermieden wird (Erne o. J., S. 1). So wurde der leane Gedanke auf die Tätigkeitsbereiche Produktion (Lean Production), administrative Aufgaben (Lean Administration), Entwicklung (Lean Development) und Management (Lean Management) angewendet (Erne o. J., S. 1-2; Karim und Nekoufar 2011, S. 1). Nach Ohno (1988 nach Erne o. J., S. 1) sollten folgende sieben Quellen von Verschwendung vermieden werden, um der leanen Denkweise gerecht zu werden:

[...]

---

^[1] Vertiefende Informationen zu Scrum finden sich in Pichler (2008).

^[2] Vertiefende Informationen zu eXtreme Programming finden sich in Beck (2000).

^[3] Determinismus bedeutet, dass zukünftige Ereignisse durch Vorbedingungen und konkreten Gesetzmäßigkeiten vorherbestimmt sind. Vertiefende Informationen finden sich in Schmidt (1999).

^[4] Vertiefende Informationen dazu finden sich in Dijksterhuis (1983).

^[5] In der Literatur finden sich unterschiedliche Abgrenzungen und Auslegungen der Phasen.

^[6] Cockburn (2002) zitiert selbst nach Goldman et al. (1995, S. 42).