Critical Chain Project Management bei Projekten in der Softwareentwicklung.

INHALTSVERZEICHNIS

I. DANKSAGUNG

II. INHALTSVERZEICHNIS

III. ABBILDUNGSVERZEICHNIS

IV. TABELLENVERZEICHNIS

1 EINLEITUNG
1.1 Summary
1.2 Inhalt der Arbeit
1.3 Begründung zur Auswahl der ausgewälten Thematik
1.3.1 Analyse der Ausgangs- / Ist-Situation
1.3.2 Persönlicher Hintergrund des Autors

2 ZIELFORMULIERUNG
2.1 Ziele
2.2 Abgrenzung

3 METHODISCHE ERLÄUTERUNGEN
3.1 Vorgehensweise
3.2 Leitspruch

4 ALLGEMEINE GRUNDLAGEN PROJEKTMANAGEMENT / IT-PROJEKTMANAGEMENT
4.1 Historie des Projektmanagements, agilen Projektmanagements und der Theory of Constraints
4.2 Was ist ein Projekt?
4.2.1 Merkmale eines Projektes
4.2.2 Arten von Projekten
4.3 Projektmanagementdefinition
4.4 Der Projektmanagementprozess
4.4.1 Der Projektmanagementprozess nach Nextlevel
4.4.2 Der Projektmanagementprozess am Praxisbeispiel der T-Systems
4.5 Aufgaben des Projektmanagements
4.6 Ziele des Projektmanagements
4.6.1 Magisches Zieldreieck
4.6.2 Teufelsquadrat
4.6.3 Funktion von Zielen
4.7 Projektrisikomanagement
4.8 Projektcontrolling
4.9 Multiprojektmanagement / Programm-Management
4.9.1 Programm-Management
4.9.2 Multiprojektmanagement
4.10 Management by Projects
4.11 Systemisches Projektmanagement

5 IT-PROJEKT / SOFTWAREENTWICKLUNGSPROJEKT
5.1 Aktivitäten / Phasen eines Softwareprojektes
5.2 Beispiel aus der Informatiklehre
5.3 Beispielhafter Ablauf eines IT-Projektes bei der T-Home
5.4 Beispielhafter Ablauf eines IT-Projektes bei der T-Systems
5.5 Basisziele im Rahmen der Softwareentwicklung
5.6 Fazit Softwareentwicklungsprojekte

6 SITUATION IN IT-PROJEKTEN
6.1 Situation in IT-Projekten generell
6.2 Bisherige alternative Projektmanagementansätze in der IT
6.3 Agile Softwareentwicklung
6.4 Agiles Projektmanagement
6.5 Bekannte Ansätze Projektmanagement in der SW-Entwicklung
6.5.1 Scrum
6.5.2 Rational Unified Process - RUP
6.5.3 V-Modell XT
6.5.4 Spiralmodell
6.5.5 Rapid Application Development
6.5.6 Extreme Programming - XP
6.6 Fazit, bisherige Ansätze

7 CRITICAL CHAIN PROJECT MANAGEMENT
7.1 Theory of Constraints / Constraint Management
7.1.1 Allgemeines zur Theory of Constraints
7.1.2 Übersicht der TOC-Denkprozesse
7.1.3 Die zugrunde liegenden Logiken der TOC-Denkprozesse
7.1.4 Logikdiagramme der Theory of Constraints
7.1.4.1 Gegenwartsbaum (engl: Current Reality Tree - CRT)
7.1.4.2 Konfliktlösungsbaum oder auch Dilemma-Wolke
7.1.4.2.1 Konfliktlösungsbaum
7.1.4.2.2 Dilemma-Wolke
7.1.4.3 Zukunftsbaum (engl.: Future Reality Tree - FRT)
7.1.4.4 Vorbehaltsbaum
7.1.4.5 Umsetzungsbaum (engl: Transition Tree - TRT)
7.1.5 Regeln zur Erstellung und Prüfung der TOC-Bäume
7.2 Critical Chain Project Management Theory
7.2.1 Vorgänge werden mit Zeitpuffer geschätzt
7.2.2 Wie eingebaute Reserven verbraucht werden
7.2.2.1 Parkinsons Gesetz
7.2.2.2 Studentensyndrom
7.2.2.3 Negatives Multitasking
7.2.2.4 Managen von Unsicherheiten
7.2.3 Der Critical Chain Projektplan
7.2.3.1 Das Late-Start-Prinzip
7.2.3.2 Staffelläuferprinzip
7.2.3.3 Definition der kritischen Kette
7.2.3.4 Ressourcenabgleich bei CCPM
7.2.3.5 Einfügen von Puffer
7.2.3.5.1 Projektpuffer
7.2.3.5.2 Zulieferkettenpuffer
7.2.3.5.3 Ressourcenpuffer
7.2.3.5.4 Pufferberechnungsmethoden
7.3 Die wesentlichen Unterschiede zum herkömmlichen PM

8 CRITICAL CHAIN PROJECT MANAGEMENT ALS ANSATZ FÜR SOFTWAREENTWICKLUNGSPROJEKTE
8.1 Grundsätze zur Beachtung
8.2 Schätzmethoden als Grundlage
8.3 Denkbarer Ablauf im Rahmen einer Iteration
8.4 CCPM gespiegelt an den Hauptproblemen der Softwareentwicklung
8.5 CCPM in der Softwareentwicklung

9 WARUM HAT SICH CCPM BISHER NICHT DURCHGESETZT BZW.WIRD ES SICH IN ZUKUNFT DURCHSETZEN KÖNNEN?

10 ERFOLGSFAKTOREN BEI EINER MÖGLICHEN EINFÜHRUNG
10.1 Changemanagement für die Einführung von CCPM
10.2 Das Seven-S-Modell - passend für CCPM
10.3 Pilotierung von Critical Chain Project Management
10.4 Ganzheitliche Einführung von Critical Chain Project Management

11 WELCHE SOFTWARE UNTERSTÜTZT CRITICAL CHAIN PROJECT MANAGEMENT?

12 HANDLUNGSEMPFEHLUNG BEZÜGLICH DES EINSATZES VON CRITICAL CHAIN PROJECT MANAGEMENT
12.1 Zusammenfassung
12.2 Fazit / Empfehlung

13 EIGENER ANSATZ - SCRUM MEETS CCPM

14 AUSBLICK PROJEKTMANAGEMENT IN DER SOFTWAREENTWICKLUNG
14.1 Status Quo - Projektmanagement in der Softwareentwicklung
14.2 Zukünftiges Projektmanagement in der Softwareentwicklung

15 GLOSSAR

16 LITERATURVERZEICHNIS

17 EIDESSTATTLICHE ERKLÄRUNG

I. DANKSAGUNG

Mit der Erstellung dieser Masterthesis geht ein Stück des Weges, den ich nicht allein gegangen bin, zu Ende. Die knapp zwei Jahre im Rahmen des MBA-Studiums waren eine anstrengende, lehrreiche und hochinteressante Zeit. An dieser Stelle möchte ich allen, die mir in dieser Zeit zur Seite gestanden haben, ganz herzlich für ihre Unterstützung danken.

An erster Stelle sei hier natürlich meine Familie genannt: meine Frau Sanne und mein Sohn Moritz, die in diesen knapp zwei Jahren doch einiges an Entbehrungen auf sich nehmen mussten und mir zusätzlich noch den Rücken frei gehalten haben. Sie haben mir in dieser besonderen Situation, genauso wie meine Eltern oder meine Schwiegermutter, bedingungslos beigestanden. Ohne ihren Zuspruch und die ganze Unterstützung wäre das gesamte Studium in dieser Form nicht machbar gewesen.

Ebenso möchte ich mich bei meinem Arbeitgeber, der T-Systems, ganz herzlich für die Aufnahme in das Projektmanagement-Förderprogramm bedanken, durch das mir die Teilnahme an diesem MBA-Studium überhaupt erst möglich wurde. Besonderer Dank gebührt hier meinem ehemaligen Vorgesetzten, Herrn Christian Droste, der mich in der entscheidenden Phase beraten und dazu motiviert hat, diesen Schritt zu wagen.

Ebenfalls bedanke ich mich bei meinen Kolleginnen und Kollegen der T-Systems, insbesondere bei meinem Team aus dem Projekt T-Home SIT, ohne deren Verständnis und Rückendeckung das alles so „nebenbei“ ebenfalls nicht zu erledigen gewesen wäre. Besonderer Dank gebührt hier den Damen Monika Steiner, Silke Heim und Nadine Schmitt sowie den Herren Dirk Geble und Benni Bertram.

Ich danke auch Herrn Peter Felske von der CSC-Akademie, der mir bei fachlichen Rückfragen im Rahmen des Studiums ein angenehmer und kompetenter Ansprechpartner war und ist.

Letzten Endes war dieses Studium aber auch wegen der Kurszusammensetzung und der einzelnen Teilnehmer/innen ein voller Erfolg. Im Besonderen möchte ich mich hier bei den Herren Thomas Oechslin, Martin Fabian, Roland Schwaiger und Christian Monschein bedanken - die zahlreichen Diskussionen, Gruppenarbeiten und Erlebnisse im Rahmen dieses Studiums haben mir viele verschiedene Sichtweisen ermöglicht und ich möchte diese gemeinsamen Erfahrungen nicht missen.

III. ABBILDUNGSVERZEICHNIS

Abbildung 1: - Nextlevel PM-Prozess

Abbildung 2 - PM-Prozess der T-Systems

Abbildung 3 - Magisches Dreieck des PM

Abbildung 4 - Teufelsquadrat

Abbildung 5 - Risikomanagement

Abbildung 6 - Multiprojektmanagement

Abbildung 7 - Hypothesenbildung

Abbildung 8 - Entwicklungsprozess

Abbildung 9 - KernProzess 14 C

Abbildung 10 - PM-Prozess der T-Systems

Abbildung 11 - Agiles PM nach Oose

Abbildung 12 - Scrum

Abbildung 13 - RUP

Abbildung 14 - V-Modell XT

Abbildung 15 - Spiralmodell

Abbildung 16 - Ursache/Wirkungsverknüpfung

Abbildung 17 - Sufficient-Cause-Logik

Abbildung 18 - Gegenwartsbaum

Abbildung 19 - Konfliktlösungsbaum

Abbildung 20 - Dilemma-Wolke

Abbildung 21 - Zukunftsbaum

Abbildung 22 - Vorbehaltsbaum

Abbildung 23 - Umsetzungsbaum

Abbildung 24 - Gauss-Verteilung

Abbildung 25 - Negatives Multitasking

Abbildung 26 - Ressourcenkritischer Pfad

Abbildung 27 - Ressourcennivellierter kritischer Pfad

Abbildung 28 - Kritische Kette

Abbildung 29 - Projektpuffer

Abbildung 30 - Zulieferkettenpuffer

Abbildung 31 - Ressourcenpuffer

Abbildung 32 - 50%-Variante

Abbildung 33 - Aufwandsverhältnis

Abbildung 34 - Seven-S-Modell

Abbildung 35 - Scrum meets CCPM

IV. TABELLENVERZEICHNIS

Tabelle 1 - Bekannte Projektkrisen IT-Großprojekte

Tabelle 2 - Projektarten

Tabelle 3 - Haupt- und Teilaufgaben des Projektmanagements

Tabelle 4 - Übersicht der TOC-Denkprozesse

Tabelle 5 - Wesentliche Unterschiede

Tabelle 6 - Vergleich Software für CCPM

1 EINLEITUNG

1.1 Summary

In dieser Arbeit wird der Einsatz der Methode Critical Chain Management (CCMj im Rahmen von Softwareentwicklungsprojekten (IT-Projekten) näher untersucht. Die Methode selbst beruht auf den Erkenntnissen der so genannten „Theory of Constraints“ von Dr. Eliyahu M. Goldratt. Im Rahmen von Projekten der produzierenden Industrie wurden hier schon beachtliche Geschwindigkeitsvorteile erzielt.

Dieser Ansatz selbst ist in Deutschland, ja sogar in Gesamt-Europa, noch nicht stark verbreitet. Sie stammt aus der Produktionsplanung und hatte zunächst das klare Ziel, den Durchsatz in der Produktion deutlich zu erhöhen. Aus der Systemtheorie und der Kybernetik entstand dann letzten Endes die „Theory of Constraints“, die die Begrenzungen der Produktion verdeutlicht und auf Basis der analysierten Daten Maßnahmen ableiten lässt, die zur Erhöhung der Produktion und zur Erhöhung des Durchsatzes führen. Grundsätzlich ist es doch so, dass ein Projektmanager oder Multi­Projektmanager (auch Programm-Manager) und ein Produktionsmanager zwei sehr ähnliche Zielvorgaben erfüllen müssen. Auf der einen Seite wollen sie so wirtschaftlich wie möglich arbeiten und alle vorhandenen Ressourcen vollständig auslasten; auf der anderen soll die Flexibilität, kurzfristig auf geänderte Markt- oder Kundenbedürfnisse reagieren zu können, erhalten bleiben (vgl. Schragenheim, 2008).

In der Praxis ergibt sich aus diesen beiden Zielen sehr häufig ein Zielkonflikt, man spricht hier auch von der so genannten „Zielkonkurrenz“ (Schell 2005, S. 144). Dieser Zielkonflikt lässt sich, wie der Begründer der "Theory of Constraints" (TOC) Dr. Eliyahu M. Goldratt in seinen Büchern erläutert, durch eine Fokussierung auf den so genannten Engpass im Unternehmen auflösen. Projekt- wie Produktionsmanager könnten also mittels Konzentration auf den Engpass die Organisation zur höchstmöglichen Leistung und auf Wachstumskurs bringen. So kann die Effizienzreduzierung eines Produktionsschritts oder eines Prozesses den Durchsatz und die Produktivität der Linien bzw. der Projektorganisation erhöhen.

Linienorientiertes Produktionsmanagement und temporäres Projektmanagement - auf den ersten Blick handelt es sich um zwei verschiedene Welten. Doch die Schwierigkeiten, mit denen Produktionsmanager und Projektmanager in der Praxis konfrontiert werden, ähneln sich letzten Endes doch. In komplexen Projekten oder auch bei der Erstellung von Einsatzplänen weisen sie Mitarbeitern und Maschinen Aufgaben zu. Alle Ressourcen werden bestmöglich ausgelastet und möglichst gewinnbringend eingesetzt (vgl. Schragenheim, 2008). Doch diese Planungen werden relativ schnell zur Makulatur, immer wieder müssen die jeweiligen Manager eine Planungsänderung vornehmen: Eilige Aufträge werden kurzfristig dazwischen geschoben und bereits angelaufene Arbeiten müssen dafür unterbrochen oder verschoben werden. Kunden wünschen kurzfristig Änderungen oder Sonderlieferungen, die andere Projekte oder Produktionsaufträge verzögern. IT-Technologien verändern sich rasant, somit wird aus dem geplanten Vorgehen eher ein so genanntes ad-hoc-Management oder auch Troubleshooting. In vielen Fällen wird dies dann nahtlos zum Krisenmanagement. Die wenig flexible Planung vieler Manager passt nicht mit dem Wunsch des Marktes nach Flexibilität, nach kurzen Lieferzeiten und gleichzeitig pünktlicher Lieferung überein.

„Doch gerade in dieser Flexibilität liegen heute erhebliche Vorteile für den Wettbewerb“ (Schragenheim 2008, S. 1).

Was den meisten Managern in dieser Situation fehlt, sind ausreichend verfügbare Ressourcen. Die Manager wissen, dass sie flexibel reagieren könnten, wenn nur ausreichend Reserve-Ressourcen vorhanden wären. Mit diesen so genannten Reserve­Ressourcen wäre es möglich, bei verstärkter Nachfrage, bei eiligen Aufträgen und ungeplanten Änderungen diese entsprechend einzusetzen. Solche zusätzlichen Ressourcen kosten allerdings weiteres Geld. Und: Diese Reserve-Ressourcen können nicht ständig ausgelastet werden und deshalb bringen sie finanzielle Verluste bzw. das Budget für diese Reserve wird erst gar nicht von der Geschäftsleitung oder vom so genannten Projektauftraggeber bewilligt (vgl. Goldratt, 1997). Flexibilität am Markt bei vollständiger Auslastung der Ressourcen - diese beiden Ziele stehen zunächst klar in Konkurrenz (vgl. auch Seite 12 - Zielkonkurrenz) zueinander.

Ein Exkurs in die Produktion macht deutlich, wie kompliziert sich das Ganze in der Praxis gestaltet. Nehmen wir an, dass in einer Produktionsanlage unterschiedliche Produkte produziert werden. Man fertigt eine bestimmte Menge jeweils eines Produktes oder Teilproduktes an einem Stück. Diese Vorgehensweise wird, in der Produktion, als Los bezeichnet. Ist ein solches Los eines Produkts abgeschlossen, werden die Maschinen angehalten und für die nächste Fertigung umgerüstet. Während dieses Rüstvorgangs stehen die Maschinen still. Je größer nun diese Lose sind, desto länger kann die Maschine ohne Unterbrechung arbeiten. Bei kleinen Losen müssen häufig Rüstzeiten (Stillstände) in Kauf genommen werden. Es erscheint also durchaus sinnvoll große Lose zu produzieren. Doch so einfach diese Lösung auch erscheint, so leicht ist sie leider nicht, insbesondere mit Blick auf die vom Markt geforderte Flexibilität. Der Markt kann bedingt durch verlängerte Lieferzeiten nicht ausreichend schnell bedient werden. Lange Lieferzeiten können nur durch ein Entgegenkommen im Preis am Markt aufgefangen werden, niedrigere Preise am Markt erfordern Kostensenkungsprogramme im Unternehmen, ein Teufelskreis entsteht (Dr. Goldratt, 1997). Um Schwankungen auszu­gleichen werden häufig auch umfangreiche Lager angelegt. Doch Lager binden das Kapital und erfordern umfangreiches Management. Ein wirklich komplexes Thema, generell sollte die „Minimierung der Produktionskosten“ (Wöhe 2005, S. 409) das wichtigste Ziel bei der Planung eines Loses sein.

Grundsätzlich ist diese Problematik auch im Projektmanagement in abgewandelter Form bekannt. Bestmögliche Nutzung der vorhandenen Humanressourcen (Mitarbeiter/innen), die Arbeitszeit einer jeden Ressource soll, als produktive Zeit, möglichst vollständig auf das Konto einzelner Projekte gebucht werden. Dies ist zumeist, gerade bei IT- Dienstleistern, auch Vorgabe des Linienmanagements. Die hohe Auslastung der Mitarbeiter ist in diesen Unternehmen sehr oft eines der wichtigsten Ziele der Linienorganisation und Bestandteil der Zielvereinbarungen der Linienmanager. Konflikte sind hier vorprogrammiert.

Auf Störungen, Verzögerungen oder Change Requests können Projektmanager, im Rahmen Ihrer Projekte, mangels freier Ressourcen kaum reagieren. So sehen sie sich ebenso wie Produktionsmanager oft gezwungen Prioritäten und Pläne zu verändern. Der Ressourcen-Einsatz erfolgt, bedingt durch die Knappheit, stark fokussiert auf Arbeitspakete, die bereits in Verzug geraten sind. Oft auch nach dem Motto: „Wer am lautesten schreit erhält das Personal“ (vgl. Lörz / Techt, 2007). In der Folge kommt es, mangels Ressourcen, zu Problemen in vorher unkritischen Bereichen. Es entsteht ein Domino-Effekt. „Viele dieser Schwierigkeiten drehen sich um das Problem, entweder die Ressourcen wirtschaftlich voll auszulasten oder flexibel auf den Markt und seine Bedürfnisse zu reagieren, sagt Unternehmensberater Eli Schragenheim, ein sehr enger Mitarbeiter von Dr. Goldratt. Aus diesem Dilemma wissen die meisten Manager keinen Ausweg" (Schragenheim 2008, S. 1 f).

Natürlich lassen sich Produktion und Projektmanagement nicht unmittelbar miteinander vergleichen, doch ist es gerade durch die Erkenntnisse aus der Produktionswelt wichtig Einsichten und Anregungen für das Projektmanagement zu gewinnen.

Grundsätzlich sollte auch im Projektmanagement gelten: Das Projektmanagement muss den Kundenanforderungen oder Marktbedürfnissen folgen. Eine erste Konsequenz aus diesen Überlegungen: Der Kunde bzw. der Markt fordert möglichst kurze Projektlaufzeiten mit zuverlässiger Einhaltung der vereinbarten Termine. Dieser Forderung ist die Projektorganisation und die Projektplanung unterzuordnen. Projekte müssen so schnell wie möglich und in jedem Fall pünktlich abgewickelt werden. In der Praxis entstehen allerdings eine Vielzahl von Verzögerungen - vor allem deshalb, weil die Mitarbeiter ihre Projektaufgaben nicht sofort dann übernehmen können wenn sie fällig werden.

Die Folge: Die Projekte müssen warten. Grundsätzlich sollte der Projektmanager die Auslastung seiner Mitarbeiter so bemessen, dass sie flexibel zur Verfügung stehen wenn sie gebraucht werden. So sollte ihnen beispielsweise ermöglicht werden, die Übergabe einer Aufgabe sozusagen untätig (Leerlauf) abzuwarten, um nach der Übergabe die übertragende Arbeit direkt starten zu können - anstatt vorher, bedingt durch maximale Auslastungsanforderungen, eine andere Aufgabe zu beginnen, die dann noch abgeschlossen werden muss (vgl. Schragenheim, 2008). Dieser Schritt ist leicht ausgesprochen oder aufgeschrieben, erfordert jedoch ein konsequentes Umdenken: Nicht die permanente Versorgung mit Aufgaben führt zum maximalen Erfolg, sondern die Akzeptanz zum Leerlauf für einzelne, wenn es dem Gesamterfolg dient. Dieses Umdenken hat also schon Einfluss auf die grundlegende Zieldefinition des Unternehmens.

Eine weitere Konsequenz aus diesen Überlegungen lautet: Wir müssen uns mit der Identifikation der Engpässe beschäftigen. Was ist in der Projektorganisation eigentlich eine Engpass-Ressource bzw. wer zeichnet für sie verantwortlich? Zumeist handelt es sich hier um bestimmte Schlüsselressourcen, in der Praxis oft auch als Keyplayer bezeichnet. Im IT-Umfeld sind das in der Regel die Architekten oder Chefentwickler. Die Linienorganisation kann nicht mehr Projekte abwickeln als diese Engpass-Mitarbeiter bearbeiten können. Aufgabe des Projektmanagers ist es, diesen Engpass bestmöglich zu nutzen. Die Nicht-Engpass-Mitarbeiter müssen den Engpass-Kollegen optimal zuarbeiten, sodass diesem die Arbeit nicht ausgeht. Und: Die Engpass-Mitarbeiter dürfen nicht mit Arbeit überlastet werden. Die Überlastung würde zwangsläufig zu schädlichem Multitasking (siehe auch Kapitel 7.2.2.3) führen, bei dem die Engpass-Mitarbeiter zwischen angefangenen Aufgaben springen, sich ggf. verzetteln und dabei wertvolle Zeit verlieren.

Der Projektmanager in einem Critical Chain Project muss also ermöglichen, dass die Engpass-Ressourcen, quasi ohne Zeitverlust, ungestört eine Aufgabe nach der anderen abwickeln können und so weit wie möglich von unnötigen Aufgaben befreit werden (vgl. Lörz / Techt, 2007). Auch dies ist in der Praxis wieder ein sehr schwieriges Unterfangen, da solche Keyplayer sehr oft sowohl innerhalb des Projektes als auch außerhalb für unterschiedlichste Aufgaben herangezogen werden. Beispielhaft aufgeführt sei hier der kurzfristige Einsatz zur Unterstützung eines Akquisitionsgespräches. Auch wieder ein Teufelskreis, denn: Ohne die ungeplante Hilfe geht eventuell ein neuer Auftrag verloren, durch die zusätzliche Arbeit wird unter Umständen ein laufender Auftrag gefährdet.

Mittlerweile ist die Critical Chain Project Management Methode auch schon in einigen Fällen erfolgreich auf das Projektgeschäft übertragen worden. Im Projekt-Management zielt die Methode auf die kritischen Faktoren und Abhängigkeiten innerhalb eines Projektes und setzt beim Projektmitarbeiter und der Planung an. Die wesentlichen Annahmen sind hier, dass im heute vorherrschenden Vorgehen (vgl. auch Hartmann, 2007) die Folgenden Einschränkungen existieren:

Störungen in den Einzelprozessen haben eine unmittelbare Auswirkung auf den Endtermin und damit auf die Kosten eines Projektes. Zeitvorsprünge sowie Kosteneinsparungen, die durch die Mitarbeiter selbst als Sicherheitspuffer in Einzelvorgängen eingeplant wurden, aber dann nicht benötigt wurden, werden nicht weitergereicht. Mitarbeiter, die schneller als geplant fertig werden, kommunizieren diesen Umstand nicht, um nicht höhere Anforderungen für spätere Vorgänge in Kauf nehmen zu müssen Das so genannte „Studentensyndrom“ (siehe auch Kapitel 7.2.2.2). „Aufgrund des Studentensyndroms und der Philosophie, ein Projekt strikt nach Kalender durchzuführen, wird entstehender Puffer so gut wie immer vollständig ausgenutzt oder sogar überschritten“ (Dr. Goldratt 1997, S. 132 ff).

Die oben schon angeführten Gründe sind auch für den Einsatz in Software­entwicklungsprojekten sehr interessant. Hier gibt es zwar bereits heute schon diverse unterschiedliche Ansätze (vor allem agile Ansätze) bezüglich schnellerer Umsetzungs­geschwindigkeit und flexiblerer Abwicklung.

Jedoch erfüllte keiner der Ansätze bisher die Kriterien eines ganzheitlichen Management bzw. Projektmanagementansatzes, was unter anderem bei öffentlichen Ausschreibungen zu Problemen bzw. Ablehnung führt. Die Projektmanagementmethoden im IT-Umfeld müssen weiter professionalisiert werden ohne dass Flexibilität und Geschwindigkeit leiden.

1.2 Inhalt der Arbeit

Die Ausgangslage für Softwareentwicklungsprojekte ist hinsichtlich der grundlegenden Anforderungen fast immer gleich: Schnelle Marktreife bei hoher Effizienz und niedrigen Kosten stehen als Forderung an diese Projekte im Raum. Dies erfordert, neben den existierenden Offshore- und Industrialisierungsbemühungen, Handlungsbedarf im Bereich der Projektmanagement-Methoden. Im Rahmen dieser Masterthesis werden, mit Blick auf die besonderen Anforderungen an die Projekte im Bereich der Softwareentwicklung, folgende Aspekte der „Theory of Constraints“ bzw. der „Critical Chain Project Management-Methode“ näher untersucht:

- Projektmanagement-Grundlagen
- Situationsbeschreibung in IT-Projekten
- Was ist Critical Chain Management / Critical Chain Projektmanagement?
- Was ist die Theory of Constraints / Constraint Management?
- Verbindung zwischen Projektmanagement und der Theory of Constraints bzw. dem Constraint Management
- Bereits bekannte Ansätze im IT-Projektmanagement
- Unterscheidung / Abgrenzung zum normalen Projektmanagement
- Critical Chain Project Management als Ansatz für Softwareentwicklungsprojekte
- Warum hat sich Critical Chain Project Management bisher nicht durchgesetzt und kann es sich in Zukunft durchsetzen?
- Handlungsempfehlung bezüglich des Einsatzes von Critical Chain Project Management
- Persönliches Fazit
- Vorstellung eines eigenen Ansatzes

Ausblick Projektmanagement in der Softwareentwicklung

1.3 Begründung zur Auswahl der ausgewählten Thematik

Mit der folgenden Beschreibung der Ausgangs und Ist-Situation im Umfeld von IT- Projekten möchte die Auswahl meines Themas näher begründen.

1.3.1 Analyse der Ausgangs- / Ist-Situation

Unternehmen bzw. Organisationen stehen vor der Aufgabe immer mehr Anforderungen in immer kürzerer Zeit umsetzen zu müssen. Darüber hinaus besteht der wirtschaftliche Druck, effektiver und effizienter zu arbeiten. Die Bedeutung von IT im Zusammenhang mit diesen Zielen und zur Unterstützung der Geschäftsprozesse einer Organisation ist unstrittig. IT-Projekte stehen deshalb sehr stark unter dem Druck, in sehr kurzer Zeit komplexe Themen zu behandeln und ein qualitativ hochwertiges Ergebnis zu liefern. Obwohl dies bekannt ist, stehen viele Projekte vor dem Problem, dass sie zu spät fertig werden, dass das Budget deutlich überzogen wird und die Ergebnisse nicht zu den Anforderungen passen. Einige Projekte werden sogar abgebrochen. Viele IT-Projekte, obwohl mit unterschiedlichstem Kontext und in unterschiedlichsten Firmen, Branchen bzw. Ländern stehen vor denselben Problemen:

- Unklare oder ungenaue Anforderungen
- Nicht genügend Zeit zur Vorbereitung (Initialisierung)
- Wechselnde bzw. neue Anforderungen (Change Requests)
- Zeitdruck
- Personalfluktuation im Unternehmen und damit auch im Projekt
- Prioritätskonflikte zwischen Projekten bzgl. Personaleinsatz
- Geringe Budgets, Kostendruck bzw. falsche Abschätzung, Budgetstreichung im Projektverlauf
- Technologiewandel während der Projektlaufzeit
- Spannungsfeld zwischen Fachbereichen, IT-Abteilungen und letzten Endes auch dem Betrieb

Diese und weitere Probleme sind Auslöser dafür, dass die Statistik bzgl. erfolgreicher IT-Projekte ein eher negatives Ergebnis aufzeigt (vgl. Wallmüller, 2004).

- Ca. 23 % der IT- Projekte werden vor ihrer Fertigstellung abgebrochen
- Ca. 49 % der IT-Projekte haben deutlich mehr Budget verbraucht (Overrun) und die Laufzeit war deutlich länger als ursprünglich geplant (190 % im Durchschnitt)
- Ca. 28 % der Projekte konnten zwar finanziell und zeitlich wie geplant beendet werden; bei ca. 30 % jedoch zu Lasten des ursprünglich geplanten Funktions­umfangs (Zielkonflikt des magischen Dreiecks, siehe auch Kapitel 4.6.1)

Die bekanntesten Projekte, die zusätzlich zu den oben bereits erwähnten Problemen auch noch mit dem Reputationsverlust des Auftragnehmers, bedingt durch die Veröffentlichung in diversen Medien, zu kämpfen hatten, sind in der Tabelle auf der Folgeseite kurz aufgeführt:

Tabelle 1 - Bekannte Projektkrisen IT-Großprojekte (Wallmüller 2004, S.1)

Abbildung in dieser Leseprobe nicht enthalten

Diese Liste ist nicht vollständig und könnte beliebig erweitert werden. Gerade in Deutschland haben auch in jüngster Zeit noch die Projekte Herkules (Bundeswehr) sowie ALG2 (Bundesanstalt für Arbeit), für negative Schlagzeilen gesorgt.

Auch zahlreiche IT-Projekte innerhalb des Konzerns Deutsche Telekom klagen über verspätete Einführungen, deutlich erhöhte Kosten und viele weitere Schwierigkeiten. Paradebeispiele sind hier die deutliche Verzögerung bei der Einführung eines neuen Systems für das Ordermanagement oder auch, ganz aktuell, die Umstellung auf ein völlig neues CRM-System. Verspätungen von mehr als einem Jahr und deutlich überhöhte Kosten führen in beiden Fällen zur Unzufriedenheit nahezu aller Beteiligten im Unternehmen.

1.3.2 Persönlicher Hintergrund des Autors

Der Autor verfügt über langjährige Erfahrung im Projektmanagement und der Beratung im Umfeld von Softwareentwicklungsprojekten, Konzeptionsprojekten, Qualitätssicherung und Testprojekten. Wesentliche Themenschwerpunkte waren Projekte im Umfeld CRM- Systeme, Internetportale, Abrechnungssysteme, User-Help-Desk, auch als UHD-Systeme (Ticketsysteme) bezeichnet, bei unterschiedlichen Kunden in verschiedenen Branchen. Die unterschiedlichsten Rollen, vom Entwickler über den Projektmanager bis hin zum Projektauftraggeber, wurden im Rahmen solcher Projekte dabei vom Autor schon ausgefüllt. Das in allen Projekten vorherrschende Thema war, wie kann man das Projekt bzw. die Projekte beschleunigen und somit den erfolgreichen Projektabschluss sicherstellen. Effiziente Abwicklung, hohe Umsetzungsgeschwindigkeit waren also Themen übergreifend die wesentlichen Anforderungen, Diese, hieraus resultierenden, Fragestellung transferiert der Autor nun aus der Praxis in die hier vorliegende Arbeit und wird im folgenden prüfen und beschreiben, welche Auswirkung der hier untersuchte Ansatz der Critical Chain Projektmanagement-Methode haben könnte und wie dieser sich von herkömmlichen Projektmanagementansätzen oder den so genannten agilen Ansätzen unterscheidet.

2 ZIELFORMULIERUNG

2.1 Ziele

[Ziel 1]: Beschreibung der Ausgangslage in IT-Projekten und Würdigung der bisherigen alternativen Ansätze im IT-Projektmanagment

[Ziel 2]: Kritische Würdigung des Ansatzes der Theory of Constraints und des Critical Chain Projekt-Managements

[Ziel 3]: Theoretische Übertragung des Ansatzes für IT-Projekte

[Ziel 4]: Ableitung einer Handlungsempfehlung zum Einsatz von Critical Chain Project Management

2.2 Abgrenzung

Es ist nicht Ziel dieser Arbeit, eine neue Projektmanagement-Methode zu entwickeln bzw. die genaue Anwendung der Critical Chain Projektmanagement-Methode im Detail zu erläutern. Auch die Übertragung auf ein in der Praxis existierendes Projekt ist nicht Ziel dieser Arbeit. Ebenfalls ist es nicht Ziel, den Ansatz des Critical Chain Projekt­Managements positiv darzustellen, sofern sich im Laufe der Arbeit ergibt, dass die Ansätze aus Sicht des Autors keine erkennbare Verbesserung für die Abwicklung von IT- Projekten bewirken.

3 METHODISCHE ERLÄUTERUNGEN

3.1 Vorgehensweise

Nach einer Literatursammlung und Analyse sowie Gesprächen mit Spezialisten auf dem Gebiet des Critical Chain Managements werde ich mich zunächst im Rahmen dieser Masterhesis mit allgemeinen Projektmanagementgrundlagen, die im Kontext von IT- Projekten besondere Bedeutung haben, beschäftigen und im folgenden Bezug nehmen auf die Ansätze der agilen Softwareentwicklung bzw. des agilen Projektmanagements, das sich unter dem Aspekt von Geschwindigkeit und Flexibilität im Bereich der Softwareentwicklung durchaus etabliert hat. Darauf aufbauend werde ich mich zunächst mit den Grundlagen der Critical Chain Projektmanagement-Methode befassen und hier im besonderen die dem Ansatz des Critical Chain Managements zugrunde liegende Theory of Constraints näher erläutern.

Ferner werde ich die Übertragung auf das IT-Projektmanagement und die dort vorherrschenden Probleme und Anforderungen beschreiben. Auf Basis der von mir bisher gemachten Erfahrungen und der im Rahmen dieser Arbeit gewonnenen Erkenntnisse werde ich abschließend eine Handlungsempfehlung bezüglich eines möglichen Ansatzes im Rahmen von Softwareentwicklungsprojekten geben. Insbesondere werde ich hier auf einen Changemanagementansatz eingehen, der für diese doch komplexe Veränderung notwendig wird und mir angemessen erscheint. Ebenfalls werde ich erläutern, warum sich Critical Chain Projekt Management bisher noch nicht durchgesetzt hat.

Abschließend folgt mein persönliches Fazit mit der Integration eines Ansatzes wie ein Zusammenspiel aus existierenden Methoden des agilen Projektmanagements und dem Critical Chain Projekt Management aussehen könnte. Ein praktischer Transfer in ein aktuelles Projekt ist aufgrund komplexer Rahmenbedingungen bei meinem aktuellen Auftraggeber leider nicht möglich.

3.2 Leitspruch

Abrunden möchte ich die Begründung für die von mir gewählte Thematik zum Thema Geschwindigkeitsoptimierung oder Effizienzsteigerung in IT-Projekten mit einem aus meiner Sicht den Kern treffenden Zitat des deutschen Top-Managers Heinz Dürr:

“The Lion and Gazelle”

Every morning in Africa, a gazelle wakes up.

It knows that it must outrun the fastest lion or it will be killed. Every morning in Africa, a lion wakes up.

It knows that it must out run the slowest gazelle or it will starve.

It does not matter whether you are a lion or gazelle.

When the sun comes up you had better be running.

4 ALLGEMEINE GRUNDLAGEN PROJEKTMANAGEMENT / IT-PROJEKTMANAGEMENT

4.1 Historie des Projektmanagements, agilen Projektmanagements und der Theory of Constraints

Die Ursprünge des modernen Projektmanagements kommen in erster Linie aus dem militärischen Bereich der USA und aus den komplexen Forschungs- und Entwicklungs­programmen der NASA. Das Projektmanagement entstand aus den Anforderungen militärischer Vorhaben zu Ende des Zweiten Weltkrieges. Rüstungs- und Raketenprogramme wurden als Projekte durchgeführt (vgl. Schell, 2005). Der generelle Durchbruch für das Projektmanagement kam, trotz aller Bedenken und Widerstände, in den siebziger Jahren. Ein Umdenken hinsichtlich Verwendung und Einsatz von Projektmanagement in den einzelnen Firmen konnte sich allerdings über Jahre erstrecken. Fortschritte beim Einsatz von IT und der Gewinn neuer Erkenntnisse begünstigten jedoch die Einführung von Projektmanagement. In den neunziger Jahren war Projektmanagement schließlich anerkannt. Seit Mitte der neunziger Jahre wurde dann auch die Ausbildung und Zertifizierung der Projektmanager vorangetrieben, die heute vor allem in den anerkannten Verfahren der IPMA und der PMI mündet. Mittlerweile werden sogar Studienprogramme wie ein MBA-Studium oder das Dipl.-Zusatzstudium angeboten. Die Anzahl der zertifizierten Projektmanager nimmt ständig zu; das Berufsbild Projektmanager und Projekte sind aus der heutigen Arbeitswelt definitiv nicht mehr wegzudenken (vgl. www.gpm-ipma.de, 2008).

In den späteren Neunzigern etablierten sich dann gerade im Bereich der IT-Projekte die ersten so genannten agilen Ansätze, um das aus Ansicht vieler Experten doch etwas schwerfällige und starre Projektmanagementvorgehen auf die Anforderungen von IT- Projekten anzupassen. Die bekanntesten sind hier sicher RUP und Scrum. Auch die Anfänge der Theory of Constraints liegen schon einige Zeit zurück. Ende der siebziger Jahre wurde die Theorie vom Physiker Dr. Eliyahu M. Goldratt begründet. Sie wurde zuerst vor allem bei der Optimierung von Produktionsprozessen eingesetzt und findet ihren Ursprung vor allem in den USA. Seit Mitte der neunziger Jahre dann hielt die Theory of Constraints auch Einzug in das Projektmanagement. Gefördert vor allem durch den im Jahre 1997 erschienenen Roman „Die kritische Kette“ von Dr. Eliyahu M. Goldratt.

In den letzten Jahren wurden auch erste Projekte erfolgreich mit dieser Methode umgesetzt. Ergänzend möchte ich noch erwähnen, dass es in Deutschland schon Ende der 50er Jahre die der späteren TOC ähnliche „Engpasskonzentrierte Verhaltens- und Führungsstrategie“ , auch bekannt als EKS-Strategie, ebenfalls auf Basis der Kybernetik mit den der TOC ähnlichen Grundprinzipien wie z.B. Reduzierung des Multitasking (Verzettelung) und Konzentration auf den wirkungsvollsten Punkt gegeben hat. Der Urheber, der Systemforscher Wolfgang Mewes, hat diese Verzettelung als das zentrale Problem von Mensch und Betrieb entdeckt. Heute existierende Ansätze wie Lean­Management und Konzentration auf das Kerngeschäft haben zumindest Teile ihres Ursprungs in der EKS (vgl. Mewes, 2000) begründet. Interessant ist, dass die EKS- Strategie von einem Betriebswirtswirt (Mewes) entwickelt wurde, der von Naturwissen­schaften keine Ahnung hatte und die TOC wiederum von einem Physiker (Goldratt) entwickelt wurde, der von Betriebswirtschaft keine Ahnung hatte. Beide kommen in ihren Forschungen zu Lösungen, die allen üblichen Regeln widersprechen, sich aber dennoch praktisch glänzend bewähren.

4.2 Was ist ein Projekt?

Die offizielle Deutsche Industrie Norm (DIN 69901) für ein Projekt lautet: Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben und projektspezifische Organisation (DIN 69901).

Die beiden bekanntesten Projektmanagement-Institute (IPMA, PMI) definieren ein Projekt wie folgt:

PMI: „Ein Projekt ist ein zeitlich begrenztes Vorhaben, das unternommen wird, um ein einmaliges Produkt, eine Dienstleistung oder ein Ergebnis zu erzeugen“(PMBook der PMI 2003, S. 19 f.).

IPMA: „./. ein zeit- und kostenbeschränktes Vorhaben zur Realisierung einer Menge definierter Ergebnisse entsprechend vereinbarter Qualitätsstandards und Anforderungen (Erfüllung der Projektziele) ...“ ( Schell 2005, S. 27).

Etwas einfacher ausgedrückt bezeichnet man ein Projekt als ein Vorhaben oder eine Aufgabe mit besonderen Merkmalen (vgl. 4.2.1 ; vgl. Patzak / Ratay, 2004).

Die Abwicklung von Aufgaben, Lösung von Problemstellungen sollte in der Regel dann als Projekt betrachtet werden, wenn das Ganze relativ komplex erscheint, der Lösungsweg zunächst unbekannt ist, aber bereits eine Zielrichtung und ein Zeitrahmen vorliegen, und oder eine bereichs- bzw. fachübergreifende Zusammenarbeit erforderlich ist.

4.2.1 Merkmale eines Projektes

Projekte sind eigenständige soziale Systeme, eingebettet in das jeweilige spezifische Umfeld (Projektumwelten). Im Rahmen von Projekten entstehen häufig eigene Regeln, Arbeitsformen und auch Kulturen etc. (vgl. Patzak / Rattay, 2004). Als die wesentlichen Merkmale eines Projektes können die folgenden bezeichnet werden:

- Aufgabenorientierte Determination (Zielvereinbarung, Zielvorgabe)
- Zeitliche Determination (begrenzte Laufzeit)
- Einmaligkeit
- Neuartigkeit (Außergewöhnlichkeit)
- Komplexität
- Aufgabenbezogenes Budget
- Rechtlich-organisatorische Zuordnung (Interdisziplinarität)
- Projektorganisation ist temporär

4.2.2 Arten von Projekten

Projekte werden auf unterschiedlichen Ebenen einer Organisation bzw. eines Unternehmens ausgeführt, sie können Projektlaufzeiten von wenigen Tagen und Wochen haben aber auch über mehrere Monate oder gar Jahre hinweg andauern. Auch die Größe bzgl. des Projektbudgets oder der Anzahl der Mitarbeiter ist sehr unterschiedlich, es geht sogar bis hin zur Beteiligung mehrerer Organisationseinheiten wie z.B. spezieller Joint Ventures oder Partnerschaften, beispielsweise aktuell das Projekt Herkules für die Deutsche Bundeswehr oder das Projekt Toll Collect. Ebenfalls spricht man auch von unterschiedlichen Projektarten wie in der folgenden Tabelle aus dem Buch „Der Projektmanager der Gesellschaft für Projektmanagement“ gezeigt:

Tabelle 2 - Projektarten (vgl. auch Schell, 2003)

Abbildung in dieser Leseprobe nicht enthalten

4.3 Projektmanagementdefinition

Bei den beiden bekanntesten Projektmanagementinstituten finden sich zwei unter­schiedliche Definitionen, während bei der IPMA das Projektmanagement nach einem aufgabenorientierten Managementverständnis als die „Summe von Planungs-, Organisations- und Steuerungsaufgaben“ bezeichnet wird, die notwendig sind, um ein Projekt erfolgreich durchzuführen stellt die PMI stellt bei ihrer Definition das Wissen und die Fertigkeiten in den Vordergrund. „Projektmanagement ist die Anwendung von Wissen, Fertigkeiten, Werkzeugen und Methoden auf Projektvorgänge, um die Projekt­anforderungen zu erfüllen“ (PMBook 2003, S. 22). In beiden Fällen ist der Projekt­manager verantwortlich für das Erreichen der vereinbarten Projektziele.

Die erste Definition hat aus meiner Sicht einen höheren Stellenwert da das Wissen und die Fertigkeiten eher dem Projektmanager zuzuordnen ist als dem Management als solches.

Mit einer prozessorientierten Managementsicht auf die Aktivitäten des Projekt­managements geschaut lässt sich festhalten, dass die Planung, Organisation und Steuerung des gesamten Projektes als Projektmanagementprozess angesehen werden kann.

4.4 Der Projektmanagementprozess

Die offizielle Definition für einen Prozess lautet: „Ein Prozess ist ein Satz von in Wechselbeziehungen stehenden Mitteln und Tätigkeiten, die alle Eingaben in Ergebnisse umgestalten“ (DIN EN ISO 8402). Dabei wird unterschieden zwischen den so genannten Primärprozessen (auch als Kernprozesse bezeichnet), die unmittelbar zur Erfüllung der Kundenanforderung (Wertschöpfung) dienen und den Sekundärprozessen (unter­stützende Prozesse und Management-Prozesse), die diese Erfüllung indirekt unterstützen. Beim Projektmanagementprozess handelt es sich um einen Sekundär­prozess der Kategorie Managementprozess, der die eigentliche Leistungserbringung (Wertschöpfung oder Primärprozess; vgl. Sterrer 2006, Skript) entsprechend unterstützt.

4.4.1 Der Projektmanagementprozess nach Nextlevel

Das folgende Beispiel, Abbildung Nr. 1, zeigt die typische Zusammensetzung des Projektmanagementprozesses und dessen Aufteilung in die verschiedenen Teilprozesse, so wie der Prozess von Nextlevel definiert wurde. Ebenfalls dargestellt sind die vorgelagerten und nachrangig stattfindenden Schritte wie Projektbeauftragung und Projektevaluierung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Nextlevel PM-Prozess (Sterrer, Skript Modul 1)

Abbildung in dieser Leseprobe nicht enthalten

Die folgenden Teilprozesse werden dem Projektmanagementprozess typischerweise zugeordnet:

- Projektcontrolling (periodisch) • Projektabschluss (einmalig) • Projektkoordination (kontinuierlich) • Projektmarketing (kontinuierlich)

Verantwortlich für den PM-Prozess (häufig als Prozessowner bezeichnet) ist im Normalfall das Project-Office eines Unternehmens. Die Verantwortung für die Einhaltung im Rahmen eines Projektes liegt beim jeweiligen Projektmanager.

4.4.2 Der Projektmanagementprozess am Praxisbeispiel der T-Systems

Als Beispiel aus der Praxis finden Sie in Abbildung 2 den Projektmanagementprozess und dessen Aufgaben wie er bei der T-Systems Enterprise Service GmbH definiert wurde. Das Projektmanagement der T-Systems orientiert sich am „Body of Knowledge der PMI“ und wurde in einer leicht abgewandelten Form im so bezeichneten „TSI-PMBook“ auf die Bedürfnisse der T-Systems angepasst und entsprechend dokumentiert.

Abbildung 2 - PM-Prozess der T-Systems (Firmenintranet T-Systems, 2008))

Abbildung in dieser Leseprobe nicht enthalten

Project Management

In der Abbildung ist die Aufteilung des Hauptprozesses Project Management in seine einzelnen Teilprozesse Initiating, Planning, Executing, Controlling und Closing besonders gut zu erkennen. Die jeweiligen Teilprozesse beinhalten dann zumindest die hier aufgeführten Arbeitsschritte. An diesem Ablauf orientiert sich die gesamte Projekt­abwicklung der T-Systems sowohl für Entwicklungsprojekte als auch für Outsourcing bzw. IT-Betriebsprojekte.

4.5 Aufgaben des Projektmanagements

Die wesentlichen Haupt- und Teilaufgaben des Projektmanagements sind in der folgenden Tabelle dargestellt (vgl. Sterrer 2006, Skript Modul 1).

Tabelle 3 - Haupt- und Teilaufgaben des Projektmanagements (vgl. Sterrer 2006, Skript)

Abbildung in dieser Leseprobe nicht enthalten

4.6 Ziele des Projektmanagements

Nach offizieller Norm ist der Begriff Projektziel definiert als „Das Projektziel ist ein nachzuweisendes Ergebnis und oder eine vorgegebene Realisierungsbedingung der Gesamtaufgabe eines Projekts“ (DIN 69905). Bei der Aufstellung der Projektziele ist darauf zu achten, dass die Ziele erreichbar und quantifizierbar sind. Eine bewährte Regel für die Zieldefinition ist die so genannte S.M.A.R.T.-Regel (vgl. Schell, 2005).

Abbildung in dieser Leseprobe nicht enthalten

Dazu sollten Ziele immer möglichst positiv formuliert werden. Grundsätzlich gilt, dass die Projektziele im Einklang mit den übergeordneten strategischen Zielen des Unternehmens stehen müssen. Die Ziele anderer Projektteams bzw. Abteilungen müssen zu Koordinierungszwecken auch bekannt sein, Ziele müssen detailliert beschrieben werden (Oberziel ^ Teilziele), also einzeln erläutert und runter gebrochen bis auf die jeweilige Gruppe bzw. den einzelnen Mitarbeiter (Schell 2005, S. 144f). Darüber hinaus gibt es unterschiedliche Kategorien für die Ziele wie z.B. interne Ziele, durch den Projektauftraggeber und das Projekt selbst oder externe Ziele, die durch den Kunden und/oder die eigene Organisation vorgegeben werden. Man unterscheidet weiterhin nach Ergebniszielen (Projektende), Prozessziele (Methodik, Vorgehen) oder Nutzenziele (bei Verwendung des Ergebnisses); (vgl. Patzak / Rattay, 2004).

In der Praxis werden gerade die Nutzenziele häufig nicht im Projekt verfolgt. Ein schönes Beispiel aus der Praxis des Autors die so genannten Ratiopotentiale (Mitarbeiterabbau) im Call Center nach der Einführung einer neuen CRM-Software. Dieses Ziel kann nicht vom Projekt erreicht werden, das Projekt muss sich auf die Ergebnisziele wie z.B. Softwarequalität konzentrieren.

Wenn man sich mit den allgemeinen Zielen des Projektmanagements beschäftigt taucht in erster Linie immer der Begriff „das magische Dreieck“ auf. Manchmal findet sich in der Literatur auch die Bezeichnung „Teufelsquadrat“. Beides klingt ungeheuer mysteriös, meint aber letzten Endes nichts anderes als die im Folgenden beschriebenen Eckpfeiler für die grundlegende Zieldefinition.

Abbildung in dieser Leseprobe nicht enthalten

4.6.1 Magisches Zieldreieck

Kern der vom Auftraggeber vorgegebenen Anforderungen, die sich gegenseitig bedingen:

- Leistung / Inhalt / Qualität

- Termine • Kosten/Budget

Abbildung 3 - Magisches Dreieck des PM (vgl. u.a. Schell, 2005)

Abbildung in dieser Leseprobe nicht enthalten

4.6.2 Teufelsquadrat

Gerade im Bereich der Softwareentwicklung wird bedingt durch die vorhandenen Zielkonflikte aus dem magischen Dreieck oft vom so genannten „Teufelsquadrat“ (vgl. H. M. Sneed in H. Balzert, 2000) gesprochen. Auch beim Teufelsquadrat sind die maßgeblichen Kriterien:

- Qualität
- Leistungsumfang / Quantität
- Zeit / Entwicklungsdauer
- Kosten / Budget für ein Projekt

Auf Basis dieser Kriterien wird im Teufelsquadrat eine Fläche gebildet und die Produktivität eines Projektes beschrieben. Die Fläche selbst ist invariant. Die vier Einflussfaktoren des Teufelsquadrates stehen in Konkurrenz zueinander, was sehr schön durch das von Sneed formulierte Teufelsquadrat zum Ausdruck kommt.

Das Teufelsquadrat nach Sneed zeigt, dass, wenn man die Kosten und Entwicklungsdauer reduzieren möchte, die Diagonalen nach unten rechts bzw. links folgen müssen. Möchte man hingegen die Qualität und die Quantität wie beispielsweise den Funktionsumfang oder die Anforderungen erhöhen folgt man den Diagonalen nach oben links, respektive rechts. Möchte man nun einen oder mehrere Faktoren stärker berücksichtigen, so ist das nur möglich zu Lasten der anderen Faktoren. Wenn also z.B. das Budget oder die verfügbare Zeit gekürzt wird, dann geht dies nur zu Lasten des Umfangs oder der Qualität (vgl. H. M. Sneed in H. Balzert, 2000).

Abbildung 4 - Teufelsquadrat (Balzert, 2000)

Abbildung in dieser Leseprobe nicht enthalten

4.6.3 Funktion von Zielen

Bei den wesentlichen Funktionen der Ziele eines Projektes (Ziel der Ziele) handelt es sich um die folgenden:

- Kontrolle, bei Projektabnahme (Messbarkeit des Projektergebnisses)
- Orientierung, für Mitglieder eines Teams
- Verbindung, zwischen Teammitgliedern („Wir-Gefühl“)
- Koordination, zwischen Abteilungen, Teilprojekten etc.
- Selektion, zur Entscheidungsfindung zwischen Alternativen

Motivation, durch die Besonderheit der Aufgabe

4.7 Projektrisikomanagement

Projektrisiken sind Bedrohungen für den Projekterfolg bzw. das gesamte Projekt. Ihr Wirkungspotential liegt in der Zukunft und kann nicht direkt gesteuert werden. Das Risikomanagement als Prozess ist ein Teilprozess des Projektcontrollings und findet periodisch statt. Risikomanagement ist immer proaktiv und versucht die erkannten Bedrohungen hinsichtlich Zielerreichung, Kosten, Terminen und Umwelten unter Kontrolle zu halten. Die folgende Abbildung zeigt auf, wie sich Risikomanagement, angelehnt an den PMBook-Standard, zusammensetzt.

Abbildung 5 - Risikomanagement (Firmenintranet, T-Systems, 2007)

Abbildung in dieser Leseprobe nicht enthalten

Nur wenn die Risiken im Projekt frühzeitig identifiziert und Maßnahmen definiert bzw. umgesetzt werden, um die Risiken zu verhindern oder den Wirkungsgrad zu verringern, kann ein Projekt erfolgreich sein (vgl. Wallmüller, 2004).

4.8 Projektcontrolling

Als Projektcontrolling bezeichnet man im engeren Sinne die laufende Überwachung des Projektfortschritts und den Vergleich mit den Projektplänen. Das Projektcontrolling nimmt also Planungs-, Kontroll-, Steuerungs- und Koordinationsfunktion wahr, um die Entscheidungsträger mit den notwendigen Informationen zur Steuerung des Projektes zu versorgen (vgl. Patzak / Ratay, 2004). Projektfortschritt bedeutet in diesem Zusammen-

hang die Erreichung von (Teil-)Ergebnissen und das schrittweise Ausschöpfen von Ressourcenbudgets.

Als Faustregel für das Projektcontrolling kann man sagen: Alles, was geplant wird, muss auch Gegenstand des Controllings sein. Meist wird der Begriff Projektcontrolling aber weiter ausgelegt. Dann schließt er die Betrachtung von Risiken und die Ableitung von Maßnahmen und die Steuerung des weiteren Projektverlaufs mit ein. Wichtig ist in jedem Fall, dass das Projektcontrolling in einem angemessenen Zeitraum als zyklischer Prozess innerhalb des Projektteams oder Kernteams durchgeführt wird (vgl. Sterrer / Winkler, 2006). Wesentliche Bestandteile des Projektcontrollings sind:

- Leistungscontrolling
- Termincontrolling
- Ressourcen- und Kostencontrolling
- Controlling der Umweltbeziehungen (Soziales Projektcontrolling)

4.9 Multiprojektmanagement / Programm-Management

Einleitend soll festgehalten werden, dass die Begriffe für Multiprojekt-Management, Programm-Management, Projektportfolio-Management in der Praxis oftmals über­schneidend oder sogar synonym verwendet werden. Eine klare Abgrenzung dieser Begriffe gibt es zurzeit nicht. In den meisten Unternehmen laufen eine Vielzahl von Projekten zwischen denen diverse Abhängigkeiten bestehen parallel zueinander. Grundsätzlich unterscheidet man zwischen Programm-Management (analog zum Projekt zeitlich begrenzt) und dem Multiprojekt-Management (permanente Aufgabe). Eine weitere Differenzierung in projektorientierten Unternehmen ist die Unterscheidung zwischen dem so bezeichneten Einzelprojektmanagement (EPM), dem schon hier schon erwähnten Multiprojekt-Management (MPM) und dem Unternehmensmanagement. Die Unter­scheidung ist in Abbildung 6 noch einmal grafisch dargestellt.

4.9.1 Programm-Management

Ein Programm kann auch als Großprojekt mit einer Anzahl von Unterprojekten bezeichnet werden. Die Projekte sind in ihrer Art verwandt und das gemeinsame Management dieser Projekte bietet gewisse Vorteile, die bei einem getrennten Management der Projekte nicht möglich wäre. Programme können Elemente verwandter Arbeit umfassen, die außerhalb des Inhalts und Umfangs der einzelnen Projekte des Programms liegen. Im Gegensatz zum Projektmanagement ist das Programm-Management ein zentralisiertes, koordiniertes Management einer Gruppe von Projekten, um die strategischen Ziele und Leistungen des Programms zu erreichen (vgl. PMBook, 2003).

4.9.2 Multiprojektmanagement

Im Gegensatz zum Programm-Management ist das Multiprojekt-Management oder auch Projektportfolio-Management eine permanente Aufgabe (vgl. Schell, 2005). Ziel des Projektportfolio-Managements ist es, die Wertmaximierung des Portfolios durch gewissenhafte Untersuchung in Frage kommender Projekte und Programme, die in das Portfolio aufgenommen werden sollen, und den rechtzeitigen Ausschluss von Projekten, die den strategischen Zielen des Portfolio nicht entsprechen, sicherzustellen (vgl. PMBook, 2003). Letzten Endes geht es um die langfristige Rentabilität des Unternehmens, welche nur durch eine optimale Zusammensetzung von Projekten im Portfolio erzielt werden kann.

[...]