Gessler_Projektphasen_2010

GPM Deutsche Gesellschaft für Projektmanagement / Michael Gessler (Hrsg.)

Kompetenzbasiertes Projektmanagement (PM3)Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0 (E-Book) / unter Mitwirkung der spm swiss project management association

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdrucks und der Vervielfältigung des Buches – oder Teilen daraus – sind vorbehalten. Kein Teil des Werks darf ohne schriftli-che Genehmigung des Verlags in irgendeiner Form (Fotokopie, Mikrofilm oder andere Verfahren), auch nicht zum Zwecke der Unterrichtsgestaltung, reproduziert oder unter Verwendung elektronischer Systeme verar-beitet, vervielfältigt oder verbreitet werden.

Für alle in diesem Werk verwendeten Warennamen sowie Firmen- und Markenbezeichnungen können Schutzrechte bestehen, auch wenn diese nicht als solche gekennzeichnet sind. Deren Verwendung in diesem Werk berechtigt nicht zu der Annahme, dass diese frei verfügbar sind.

Die DIN-Normen im Fachbuch PM3 sind wiedergegeben mit Erlaubnis des DIN Deutsches Institut für Nor-mung e.V. Maßgebend für das Anwenden der DIN-Norm ist deren Fassung mit dem neuesten Ausgabedatum, die bei der Beuth Verlag GmbH, Burggrafenstraße 6, 10787 Berlin, erhältlich ist.

Layout, Satz und Grafikgestaltung: formarteam Design Studio. Umschlaggestaltung: formarteam Design Stu-dio. Titelbild: Schultze. Walther. Zahel. Kommunikationsagentur & GPM. Druck und Bindung: Labude. corpo-rate products.

GPM-Homepage: http://www.gpm-ipma.despm-Homepage: http://www.spm.chPM3-Feedback: http://www.gpm-pm3.dePM3 als E-Book: http://www.ciando.com

ISBN 978-3-924841-40-9 (Hardcover)ISBN 978-3-924841-45-4 (E-Book)

1. Auflage, 2009, 1-20002. Auflage, 2009, 2001-50003. Auflage, 2010, 5001-8000

© 2010 GPM Deutsche Gesellschaft für Projektmanagement e.V., Frankenstraße 152, 90461 Nürnberg (Deutschland / Europäische Union).

1.11

Projektphasen

© GPM (E-Book) | PM3 | PM-technische Kompetenzen 349

1.11a Projektphasen (Project phases)

Michael Gessler und Rolf Kaestner

Kontext und Bedeutung

In der ICB – IPMA Competence Baseline (IPMA 2006) bilden „Projektphasen“ und „Ablauf und Ter-mine“ ein gemeinsames Element. Nachfolgend sind diese untergliedert in die Kapitel 1.11a (Projekt-phasen) sowie 1.11b (Ablauf und Termine) jeweils mit Basiskapiteln sowie Vertiefungskapiteln. In der National Competence Baseline der GPM (NCB) sind Projektphasen wie folgt definiert: „Eine Pro-jektphase ist ein bestimmter Abschnitt des Projektablaufs, der von anderen Projektperioden klar abgegrenzt ist. Eine Projektphase beinhaltet sowohl die Erbringung wichtiger Deliverables als auch Entscheidungen, die als Grundlage für die nächste Projektphase dienen. Phasen haben klar definier-te Zielsetzungen und können auch zeitlich begrenzt sein. Bei verschiedenen Arten von Teil-Projekten können unterschiedliche Phasenmodelle zur Anwendung kommen, dies erhöht die Komplexität ihrer Koordinierung. Meilensteine erleichtern es, auf bestimmte Ziele, Phasenabschlüsse oder Intervaller-gebnisse hinzuarbeiten. In der Praxis können sich Projektphasen überlappen, so z. B. bei gleichzeitig ablaufenden Projektabschnitten oder beim Fast-Tracking.“ (GPM 2008, S. 73). Die Phasenbetrachtung bildet ein Schlüsselelement sowohl der Projektplanung als auch der Projektsteuerung. Die Bedeutung von Projektphasen sowie deren Zusammenhang mit anderen PM-Elementen wird im Kapitel 1.11a zu Beginn erläutert.

Lernziele

Sie kennen

die Bausteine eines Phasenplans. IPhasenmodelle für unterschiedliche Projektarten. I

Sie können

Vorteile der Phasenbetrachtung benennen und diskutieren. IGemeinsamkeiten und Unterschiede von Meilensteinen und Gates diskutieren. Ieinen Phasenplan erstellen entsprechend dem Muster in Abb. 1.11a-2. IVorteile von Vorgehensmodelle benennen und diskutieren. Ispezifische und übergreifende Vorgehensmodelle unterscheiden. IBausteine von Vorgehensmodellen benennen. Idas Vorgehen beim Entwickeln eines unternehmensspezifischen Vogehensmodells beschreiben. Isequentielle, wiederholende und wiederverwendende Modellfamilien unterscheiden und deren Be- Isonderheiten benennen.

Projektphasen

1.11

350 © GPM (E-Book) | PM3 | PM-technische Kompetenzen

Inhalt

1 Grundlagen 3511.1 Projektmanagementphasen und Projektphasen 3521.2 Meilensteine und Gates 3531.3 Phasenplan 3541.4 Phasenmodelle 3551.5 Vorgehensmodelle 3581.6 Lebenszyklusmodelle 3602 Flexibilisierung 3612.1 Phasenübergänge und Meilensteine 3612.2 Modellfamilien 3613 Fragen zur Wiederholung 365

1.11

Projektphasen


1 Grundlagen

! Phasen gliedern ein Projekt in zeitliche und / oder sachliche Abschnitte. Phasen schaffen eine erste Grobstruktur, ermöglichen Orientierung und reduzieren die Komplexität eines Projekts. Jede Phase erfüllt konkrete Ziele im Gesamtprojekts, weshalb zu fragen ist, was eine Phase leis-tet, was ihr Output ist. Zentrale Fragen sind sodann: In welche Abschnitte kann das Projekt un-tergegliedert werden (Phasen)? Welchen Output generieren diese Phasen (Meilensteine)?

Meilensteine sind definierte Ereignisse von besonderer Bedeutung. Hierzu zählen insbesondere (1) Liefergegenstände (eng. Deliverables) oder auch Zwischenergebnisse, (2) Prüfungen wie Abnah-men, Zwischenabnahmen oder auch Reviews sowie (3) Entscheidungen (z. B.: kann die nächste Phase starten oder nicht: go / no go)? Meilensteine liegen zudem in der Regel zu Beginn (Phasen-Freigabe) oder am Ende einer Phase (Phasen-Abschluss) und markieren damit auch die (4) Pha-senübergänge.

Die Gliederung eines Projekts in Phasen und Meilensteine bietet verschiedene Vorteile:

Projektphasen ermöglichen durch die Gliederung eines Projekts in Abschnitte bereits zu einem frü- Ihen Zeitpunkt eine erste grundsätzliche Orientierung. Sie reduzieren Komplexität! Ein Phasenplan ermöglicht bereits frühzeitig grobe Übersicht über ein Projekt. Projektphasen sind ein mögliches Gliederungsprinzip zur Erstellung eines Projektstrukturplans und Ibilden damit ein „Gelenkglied“ zwischen Grob- und Feinplanung. Sie bieten ein Ordnungsraster für die Feinstrukturierung.Projektphasen ermöglichen die phasenbezogene I Zuordnung und das phasenbezogene Controlling u. a. von Liefergegenständen, Ressourcen, Kosten und Finanzmitteln. Sie sind damit hilfreich in der Projektplanung sowie Projektsteuerung.Projektphasen ermöglichen eine phasenbezogene Planung und Anpassung der Projektorganisation. IDie Phasenübergänge bieten sodann einen systematischen Anlass zur Klärung von Zuständigkei-ten, Verantwortungen und Befugnissen für die folgende Phase.Meilensteine reduzieren das Risiko der Fehlentwicklung im und des Projekts, da z. B. mit Instrumen- Iten des Projectcontrollings der Entwicklungsfortschritt überwacht (z. B. mittels einer Meilenstein-trendanalyse), der Entwicklungsstand (z. B. mittels eines Reviews) überprüft und der Business Case (z. B. mittels der Entscheidungen des Auftraggebers) aktualisiert werden kann. Ein Projekt kann so frühzeitig kalibriert und - falls notwendig - abgebrochen werden. Meilensteine ermöglichen den geordneten I Abschluss eines Projektabschnitts (close-out) sowie den geordneten Übergang in den nächsten Projektabschnitt (start-up). Sie sind hilfreich für die Quali-tätssicherung (z. B. quality gate) und sodann für den Projektabschluss.Meilensteine ermöglichen durch die Entscheidungen zum Phasenabschluss sowie zur Phasenfreigabe Ieine kontinuierliche Einbindung des Projektauftraggebers bzw. Lenkungsausschusses.Meilensteine ermöglichen eine fortlaufende Zielorientierung für die Mitarbeiter, Erfolgserlebnisse für Isie und eine Synchronisierung der Zusammenarbeit. Sie sind damit auch ein Instrument der Führung und Motivation!

Die Gliederung eines Projekts in Phasen und Meilensteine kann allerdings auch Nachteile bedeuten:

Einerseits reduziert ein Phasenplan die Komplexität eines Projekts. Andererseits kann die frühzeitige Planung von Phasen und Meilensteinen die notwendige Flexibilität im Projektverlauf einschränken. Planung als Vorwegnahme zukünftigen Handelns stößt zudem immer dann an Grenzen, wenn die Projektbeteiligten nicht über die notwendige Erfahrung verfügen, um Aktivitäten und Ereignisse rea-listisch zu antizipieren. Planung stößt allerdings auch dann an Grenzen, wenn der individuelle Erfah-rungsstand zwar hoch ist, die sachlichen Anforderungen jedoch instabil sind und sich im Projektverlauf ändern. Insbesondere innovative Vorhaben, die oftmals unscharfe sowie instabile Anforderungen auf-weisen, können technokratisch und streng-sequentiell nur schlecht geplant werden.

Projektphasen

1.11


Ein Weg zur Flexibilisierung könnte sodann sein, das Projekt in Phasen zu untergliedern, ohne jedoch eine Detailplanung für das gesamte Projekt zu erstellen. Die Detailplanung erfolgt dann jeweils nur zum Ende einer Phase und für die nachfolgende Phase. Dieses Prinzip verwendet beispielsweise PRINCE 2: „Die Planung der nächsten Phase geschieht stets zum Ende der vorhergehenden Phase.“ (Ebel 2007: 212). Für den Phasenübergang gelte allerdings das „Schleusenprinzip“: „Grundsätzlich ist der Übergang in die nächste Phase „gesperrt“. Erst wenn das Projekt die nach Plan geforderten Ergebnisse nachge-wiesen hat, der Business Case weiterhin gewährleistet ist („viable“) und die Planung der nächsten Phase vorliegt, wird vom Lenkungsausschuss grünes Licht zum Eintritt in die nächste Phase gegeben.“ (Ebel 2007: 212). Das Schleusenprinzip schränkt die Flexibilität am Phasenübergang wieder ein.

Die Lösung des Problems „vorausschauende Planung ist nicht möglich“ lautet somit nicht, auf Planung insgesamt zu verzichten, sondern, den Zeitabstand zwischen Detailplanung und Ausführung zu verkürzen. Einen ähnlichen und dennoch anderen Weg vertreten Methoden, die zum Agilen Projekt-management zählen. Ähnlich sind diese Methoden, da sie ebenfalls mit der Verkürzung der Zeitabstän-de arbeiten. Anders sind sie, da die Abstimmung im Detail z. B. mittels täglicher Teamtreffen erfolgt. Die Absicherung der Detailplanung erfolgt nicht per Freigabe von Detailplanungsdokumenten (z. B. bei PRINCE 2), sondern kommunikativ vor Ort. Ähnlich ist auch der Einsatz von sogenannten Timeboxen, die im APM Agilen Projektmanagement, eine Methode, die Elemente von SCRUM aufgreift und vari-iert, eine zentrale Rolle spielen und an eine Kombination von Phase und Meilenstein erinnern: „Eine Timebox definiert einen unverrückbaren Zeitrahmen, an dessen Ende eine Menge von Ergebnissen in einer bestimmten Detaillierung und Vollständigkeit nachprüfbar und formal dokumentiert vorliegen soll. Liegen die Ergebnisse nicht wie geplant vor, werden die offenen Teile in eine nachfolgende Timebox verschoben. Hierzu werden zum geplanten Endtermin die tatsächlich erreichten Ergebnisse bestimmt. Eine Timebox ist ein Hilfsmittel zur Planung und Überwachung eines Entwicklungsprozesses.“ (Oester-reich & Weiss, 2008: 103). Es wird wiederum nicht auf Planung verzichtet, sondern der Phasenübergang bzw. der Übergang zwischen einer Timebox zur nächsten flexibilisiert.

Fazit: Phasen, Meilensteine und die Gestaltung der Übergänge, in welcher Form auch immer, stellen ein notwendiges PM-Instrument dar und, gleichwohl diese vorausschauende Modellierung der Wirklichkeit die Realität nie 1:1 erfasst und abbildet, ist sie dennoch notwendig.

1.1 Projektmanagementphasen und Projektphasen

Die DIN 69901-2: 2009 unterscheidet einerseits Projektmanagementphasen und andererseits Projekt-phasen. Projektmanagementphasen sind in allen Projekten gleichermaßen vorhanden, da sie – unab-hängig von der konkreten Problemstellung oder vom konkreten Kontext – grundsätzliche Anforderun-gen der Projektarbeit abbilden. Projektmanagementphasen nach DIN 69901-2:2009 sind:

Initialisierungsphase I (en: initiating phase): Gesamtheit der Tätigkeiten und Prozesse zur forma-len Initialisierung eines Projekts (u. a. Zuständigkeiten klären, Projektziele skizzieren).Definitionsphase I (en: definition phase): Gesamtheit der Tätigkeiten und Prozesse zur Definition eines Projekts (u. a. Zieldefinition, Aufwandsschätzung und Machbarkeitsbewertung). Planungsphase I (en: planning phase): Gesamtheit der Tätigkeiten und Prozesse zur formalen Pla-nung eines Projekts (u. a. Vorgänge und Arbeitspakete planen, Kosten- und Finanzmittelplan erstel-len, Risiken analysieren, Ressourcenplan erstellen).Steuerungsphase I (en: steering phase): Gesamtheit der Tätigkeiten und Prozesse zur formalen Steuerung eines Projekts (u. a. das Steuern von Terminen, Ressourcen, Kosten und Finanzmitteln, Risiken, Qualität, Ziele)Abschlussphase I (en: closing phase): Gesamtheit der Tätigkeiten und Prozesse zur formalen Been-digung eines Projekts u. a. Erstellung des Projektabschlussberichts, Nachkalkulation, Erfahrungs-sicherung, Vertragsbeendigung)

1.11

Projektphasen


Die Summe der o.g. Projektmanagementphasen bilden den Projektlebenszyklus. Die Phasen sind je-weils nach denjenigen PM-Aktivitäten benannt, die überwiegend eine PM-Phase prägen.

Projektphasen sind im, Gegensatz zu Projektmanagementphasen, produkt- bzw. gegenstandsspezi-fisch und kontextbezogen; sie unterscheiden sich von Projektart zu Projektart (z. B. Investitionsprojekt oder Organisationsprojekt), von Branche zu Branche (z. B. Baugewerbe oder Information / Kommunika-tion) und von Organisation zu Organisation.

1.2 Meilensteine und Gates

Wie eingangs erwähnt, schließt oder beginnt jede Phase mit mindestens einem Meilenstein. Meilenstei-ne liegen allerdings auch innerhalb einer Phase. Als Daumenregel gilt, dass die Zeitabstände zwischen den Meilensteinen von der Gesamtdauer eines Projekts abhängig ist: Je kürzer ein Projekt ist, desto geringer ist der zeitliche Abstand zwischen den Meilensteinen. Zahl und Zeitpunkt der Meilensteine können auch durch andere Faktoren bestimmt werden, wie Risiko, Qualität und / oder Projektorga-nisationsform. Meilensteine sind jedoch insbesondere aus den Projektzielen abzuleiten. Sie können, z. B. als Vorgehensziele, auch Bestandteil der Projektziele sein (vgl. Beitrag 1.03 Projektziele).

Für Meilensteine gilt, wie auch für die Projektziele, dass diese zu operationalisieren sind bzw. messbar gemacht werden müssen, wofür Indikatoren bzw. Kriterien erforderlich sind. Ohne vorab definierte Kriterien ist jede Überprüfung pure Willkür. In Vorgehensmodellen (Kapitel 1.5, unten) sind Meilen-steinergebnisse oftmals mit Spezifikationen in Form von z. B. Checklisten oder Formularen hinterlegt. Dies gilt insbesonders für produktzentrierte Vorgehensmodelle, die den zeitlichen Ablauf, Abhängig-keiten zwischen Arbeitsabläufen sowie Verantwortlichkeiten über Produkte (Ergebnisse) definieren und nicht über Aktivitäten. Das V-Modell XT und PRINCE 2 verfolgen diese Philosophie. Unterscheidbar ist zudem, wer wie an einem Meilensteinen beteiligt ist: An externen Meilensteinen ist der Auftragge-ber bzw. Lenkungsausschuss beteiligt. Die Entscheidung (z. B. go / no go) liegt bei externen Meilenstei-nen beim Auftraggeber bzw. Lenkungsausschuss. Interne Meilensteinen können interne Richtgrößen für das Projekt selbst sein – als Steuerungsinstrumente für den Projektleiter.

Stages und Gates: Das Stage-Gate-Prinzip (Stage=Phase, Gate=Tor) wurde in den 1960er Jahren von der NASA entwickelt. Merkmal eines Gate ist, dass alle Aktivitäten einer Phase abgeschlossen sein müssen, bevor mit der nächsten Phasen begonnen werden darf. Gates liegen am Ende einer Phase und bilden Mess- und Entscheidungspunkte im Projektablauf. Sie entsprechen damit den Meilensteinen am Ende einer Phase. Zu Beginn der 1990er Jahre erlebte das Konzept neue Beachtung: In den Konzep-ten der 2. Generation wurde insbesondere die Umfeldbetrachtung verstärkt sowie die Gate-Prüfung durch Einführung vorher festgelegter Kriterien verbessert. Geprüft wird nun insbesondere, ob alle Ergebnisse vorliegen. Betrachtet wird zudem nicht mehr nur das Projekt, sondern zudem das Umfeld (u. a. Marktrelevanz, Konkurrenz, Technologieentwicklung). Das Gate selbst blieb eine Schleuse; die-ser Ansatz führt allerdings oftmals zu Terminverzögerungen. In den Konzepten der 3. Generation (ab Mitte der 1990er Jahren) werden schließlich Überlappungen von Phasen erlaubt: Folgephasen kön-nen beginnen, sobald ein definierter Mindeststandard erreicht ist; Nacharbeiten sind innerhalb eines definierten Zeitraums in der Folgephase möglich (vgl. Abbildung 1.11a-1). Neben der Sicherung der Produktqualität spielt die Sicherung der Qualität der Integration von Lieferanten sowie insgesamt die Qualität der Synchronisierung von Prozessen von Beginn an eine zentrale Rolle, weshalb Gates oftmals auch als Quality Gates bezeichnet werden. Zur Sicherung der Qualität zählt zudem das Zusam-menspiel von Prozessen und Strukturen der Ablauf- und Aufbauorganisation im Projekt einerseits sowie der Projekt- und Stammorganisation andererseits.

Projektphasen

1.11


An einem Quality Gate wird der Fortschritt eines Projekts geprüft, bewertet und entschieden, ob zum nächsten Quality Gate vorgerückt werden kann, Ziele ggf. anzupassen sind, die Freigabe der nächsten Phase ggf. verzögert wird oder das Projekt abzubrechen ist. Die Prüfung übernehmen im Auftrag des Auftraggebers bzw. Lenkungsausschusses sogenannte Gatekeeper, die auf Basis der Ergebnisse ihrer Prüfung eine Empfehlung aussprechen. Quality Gates können helfen, die Projektlandschaft in einer Organisation durch projektübergreifende Verfahren zu steuern. Die Prüfung von Quality Gates wird oftmals als Review bezeichnet. Kerzner (2003: 59) vertritt die Meinung, dass gutes Projektmanage-ment nicht mehr als sechs Gates umfassen sollte, da ansonsten zu viel Aufmerksamkeit in die Bewer-tung fließt. Auf jeden Fall ist die Zahl der Quality Gates eher gering zu halten, während die Zahl der Meilensteine von der Zahl der Phasen sowie den Projektzielen abhängig ist.

Meilensteine sichern ziel- und ergebnisorientiertes Arbeiten im Projekt und sind ein wichtiges Steue-rungsinstrument auch für den Projektleiter. Meilensteine motivieren und erfüllen die im Beitrag 1.03 genannten Funktionen von Zielen: Kontrolle, Orientierung, Verbindung, Koordination und Selektion. Quality Gates haben einen umfassenderen Anspruch (Projekt und Umfeld, Prüfung und Synchroni-sierung, Projektteam und Auftraggeber / Lenkungsausschuss) und sind insbesondere in Projektland-schaften ein wichtiges Steuerungsinstrument. In der folgenden Abbildung ist ein Phasenmodell aus der Fahrzeugentwicklung dargestellt. Das Phasenmodell beinhaltet Qualtiy Gates und Meilensteine. Die Flexibilisierung der Quality Gates (Konzepte der 3. Generation) ist deutlich erkennbar.

Abbildung 1.11a-1: Phasenmodell in der Fahrzeugentwicklung Quelle: Eberle & Schmid 2009: S. 152

1.3 Phasenplan

Phasenpläne können bereits zu einem frühen Zeitpunkt erstellt werden, um eine schnelle Orientie-rung über das anstehende Projekt zu gewinnen. Bereits mit der ersten Zielskizze ist die Erstellung ei-nes groben Phasenplans möglich. Hilfreich ist hierbei, zunächst ein Grundschema zu verwenden (z. B. die Aufteilung in fünf Phasen nach DIN 69901-2). Dieses wird anschließend produkt- und kontextspe-zifisch konkretisiert (Zielsystem) und mit fortschreitendem Planungsprozess weiter konkretisiert. Um die Phasen zumindest grob zu spezifizieren, ist, selbst im ersten Anlauf, die phasenbezogene Benen-nung von Hauptaktivitäten hilfreich. Möglich ist oftmals auch ein erste grobe Aufwandsschätzung, die phasenbezogen top-down erfolgt. Diese erste Schätzung ist in der Regel sehr ungenau (u.U. Abwei-chungen bis zu 300 %). Hilfreich bei der Aufwandsschätzung ist z. B. der Einsatz von Analogieschlüs-sen: Existieren branchenspezifische Richtwerte? Existieren Orientierungswerte aus allgemeinen, pro-jektartbezogenen oder unternehmensspezifischen Vorgehensmodellen? Existieren Erfahrungswerte aus Projekten?

1.11

Projektphasen


Die Bezeichnug der Phasen und Meilensteine ist in der Regel unternehmensspezifisch. Es ist auch un-erheblich, wie diese heißen. Wichtig ist vielmehr, dass ein gemeinsamens Verständnis besteht, was in einer Phase geleistet werden soll und was zu einem Meilenstein erreicht worden sein soll. Meilensteine sind zu einem frühen Zeitpunkt in der Regel noch nicht genau terminiert, sondern zumeist nur grob gesetzt. Hauptaktivitäten und Aufwände werden zunächst den Phasen nur grob zugeordnet. In einem ersten Anlauf kann es nicht um Präzision gehen, sondern um ein erstes grobes Bild über den Verlauf des Projekts. Abbildung 1.11a-2 beinhaltet Phasen, Meilensteine, Hauptaktivitäten und eine Aufwand-schätzung.

Abbildung 1.11a-2: Exemplarischer Phasenplan Quelle: Eigene Darstellung

1.4 Phasenmodelle

Nachfolgend werden Beispiele für (1) Organisations- / OE-Projekte, (2) Forschungs- und Entwicklungs-projekte sowie (3) Investitionsprojekte vorgestellt (IT-Projekte siehe Beispiel im Vertiefungswissen).

Organisationsprojekte bzw. OE-Projekte: Klassische Organisationsprojekte sind die Planung und Durchführung von u. a. Messen, Kongressen, kulturellen Events und Tagungen. Ein typisches OE-Projekt wäre z. B. die Einführung eines PM-Systems. In Abbildung 1.11a-3 ist ein Phasenmodell (Initiieren, Ori-entieren, Gestalten, Implementieren) mit Hauptaktivitäten für ein Organisationsentwicklungsprojekt dargestellt, das zum Ziel hat, eine Unternehmenskultur zu verändern.

Projektphasen

1.11


Abbildung 1.11a-3: Phasenmodell zur Veränderung von Unternehmenskulturen Quelle: Ferber, Schmitz und Waibel (2005)

F&E-Projekte: Das Phasenmodell der VDI-Richtlinie 2221 „Methodik zum Entwickeln und Konstruie-ren technischer Systeme und Produkte“ bietet einen Orientierung für technische Entwicklungsprojekte mit Phasen, Aufgaben (Hauptaktivitäten) und Arbeitsergebnissen (Meilensteine). Detaillierter ausge-arbeitet wurde dieses Modell z. B. im „Münchener Vorgehensmodell (MVM)“ (vgl. Lindemann 2009).

Abbildung 1.11a-4: Phasenmodell der Produktentwicklung in der Domäne Mechanik (VDI 2221) Quelle: Bender 2005, S. 36

OE-Projekte sowie F&E-Projekte verlaufen selten rein sequentiell, sondern oftmals in Schleifen. In Kapitel 2 (unten) wird die Möglichkeit, Wiederholungen bewusst einzuplanen, thematisiert.

1.11

Projektphasen


Investitionsprojekte: Im Bauwesen, einer Branche mit insbesondere Investitionsprojekten, bestehen verschiedene Ordnungen und Richtlinien, die auf dem Prinzip „Projektphase“ aufgebaut sind. Dies sind u. a. die „Honorarordnung für Architekten und Ingenieure (HOAI)“, das verdichtete Modell vom „Aus-schuss der Verbände und Kammern der Ingenieure und Architekten für die Honorarordnung (AHO)“ sowie das Leistungsmodell SIA 112 vom „Schweizer Ingenieur- und Architektenverein (SIA)“.

In nachfolgender Tabelle ist exemplarisch das Leistungsbild „Gebäude und raumbildende Ausbau-ten“ der HOAI 2009 aufgeführt (ohne 2.6.10: besondere Leistungen). „Hauptleistungen“ entsprechen den Phasen und „Leistungsposten“ den Hauptaktivitäten. Aufgenommen wurden zudem die Aufwands-richtwerte der HOAI (vgl. die %-Angaben in der Tabelle nach § 33, HOAI 2009). In der rechten Spalte der Tabelle 1.11a-1 sind zum Vergleich die verdichteten Phasen der AHO aufgeführt.

Tabelle 1.11a-1: Leistungsbild Gebäude und raumbildende Ausbauten HOAI 2009 (PV=Projektvorbereitung)

Hauptleistung HOAI Leistungsposten HOAI AHO

Grundlagenermittlung3 %

Bestandsaufnahme, Standortanalyse, Betriebsplanung, Aufstellung eines Raumpro-gramms, Aufstellen eines Funktionsprogramms, Prüfen der Umwelterheblichkeit, Prüfen der Umweltverträglichkeit.

PV

Vorplanung7 %

Untersuchen von Lösungsmöglichkeiten nach grundsätzlich verschiedenen Anforde-rungen, Ergänzen der Vorplanungsunterlagen auf Grund besonderer Anforderungen, Aufstellen eines Finanzierungsplanes, Aufstellen einer Bauwerks- und Betriebs-Kosten-Nutzen-Analyse, Mitwirken bei der Kreditbeschaffung, Durchführen der Voranfrage (Bauanfrage), Anfertigen von Darstellungen durch besondere Techniken, wie zum Beispiel Perspektiven, Muster & Modelle, Aufstellen eines Zeit- und Organi-sationsplanes, Ergänzen der Vorplanungsunterlagen

Projektplanung

Entwurfsplanung11 % Gebäude14 % r. Ausbauten

Analyse der Alternativen / Varianten und deren Wertung mit Kostenuntersuchung (Optimierung), Wirtschaftlichkeitsberechnung, Kostenberechnung durch Aufstellen von Mengengerüsten oder Bauelementkatalog, Ausarbeitung besonderer Maßnah-men zur Gebäude- und Bauteiloptimierung

Genehmigungs-planung6 % Gebäude2 % r. Ausbauten

Mitwirken bei der Beschaffung der nachbarlichen Zustimmung, Erarbeiten von Un-terlagen für besondere Prüfverfahren, Fachliche und organisatorische Unterstützung des Bauherrn im Widerspruchsverfahren, Klageverfahren oder Ähnliches, Ändern der Genehmigungsunterlagen infolge von Umständen, die der Auftragnehmer nicht zu vertreten hat;

Ausführungsplanung25 % Gebäude30 % r. Ausbauten

Aufstellen einer detaillierten Objektbeschreibung als Baubuch zur Grundlage der Leistungsbeschreibung mit Leistungsprogramm, Aufstellen einer detaillierten Objektbeschreibung als Raumbuch zur Grundlage der Leistungsbeschreibung mit Leistungsprogramm, Prüfen der vom bauausführenden Unternehmen auf Grund der Leistungsbeschreibung mit Leistungsprogramm ausgearbeiteten Ausführungspläne auf Übereinstimmung mit der Entwurfsplanung, Erarbeiten von Detailmodellen, Prüfen und Anerkennen von Plänen Dritter, nicht an der Planung fachlich Beteiligter auf Übereinstimmung mit den Ausführungsplänen

Vorbereitung der Ausführung

Vorbereitungder Vergabe10 % Gebäude7 % r. Ausbauten

Aufstellen der Leistungsbeschreibungen mit Leistungsprogramm unter Bezug auf Baubuch / Raumbuch, Aufstellen von alternativen Leistungsbeschreibungen für geschlossene Leistungsbereiche, Aufstellen von vergleichenden Kostenübersichten unter Auswertung der Beiträge anderer an der Planung fachlich Beteiligter

Mitwirkungbei der Vergabe4 % G., 3 % rA.

Prüfen und Werten der Angebote aus Leistungsbeschreibung mit Leistungspro-gramm einschließlich Preisspiegel, Aufstellen, Prüfen und Werten von Preisspiegeln nach besonderen Anforderungen

Objektüberwachung(Bauüberwachung)31 %

Aufstellen, Überwachen und Fortschreiben eines Zahlungsplanes, Aufstellen, Über-wachen und Fortschreiben von differenzierten Zeit-, Kosten- oder Kapazitätsplänen, Tätigkeit als verantwortlicher Bauleiter, soweit diese Tätigkeit nach jeweiligem Landesrecht über die Grundleistungen hinausgeht

Ausfüh-rung

Objektbetreuung und Dokumentation3 %

Erstellen von Bestandsplänen, Aufstellen von Ausrüstungs- und Inventarverzeich-nissen, Erstellen von Wartungs- und Pflegeanweisungen, Objektbeobachtung, Objektverwaltung, Baubegehungen nach Übergabe, Überwachen der Wartungs- und Pflegeleistungen, Aufbereiten des Zahlungsmaterials für eine Objektdatei, Ermitt-lung und Kostenfeststellung zu Kostenrichtwerten, Überprüfen der Bauwerks- und Betriebs-Kosten-Nutzen-Analyse

Projektdoku. / Inbetriebnahm

e

Projektphasen

1.11


Phasenmodelle im Überblick: In der nachfolgenden Tabelle 1.11a-2 sind Beispiele unterschiedlicher Phasenmodellen im Überblick dargestellt:

Tabelle 1.11a-2: Phasenmodelle im Überblick (Quelle: Eigene Darstellung)

Projektart PhasenDIN 69901-2

(2009) Initialisierung Definition Planung Steuerung Abschluss

IT-Projekt(grob) Initialisierung Analyse Entwurf Entwicklung Abschluss

IT-Projekt(fein)

Bedarfs-identifikat.

Anforde-rungsskizze

Analyse- konzept

Analyse-prototyp.

Entwurfs-konzept

Entwurfs-prototyp.

Imple-mentat.

Integ-ration

Instal-lation

Einsatz Abschluss

Org.-Projekt(grob) Initialisierung Bedarfsermittlung Vorbereitung Durchführung Abschluss

Org.-Projekt(grob)

Vorstudie ZielskizzeBedarfs-analyse

Bedarfs-definition

PlanungVor-

bereitungTraining Einführung Sicherung Abschluss

F&E-Projekt(grob) Initialisierung Konzeptentwicklung Produktplanung Produktentwicklung Abschluss

F&E-Projekt(fein)

Problem-identifikat.

Problem-skizze

Problem-analyse

Konzept-findung

Produkt-definition

Produkt-planung

Prototyp-entwickl.

Realisie-rung

Produktion Abschluss

Invest.-Projekt(grob) Projektvorbereitung Projektplanung Vorbereitung der

Ausführung Ausführung Abschluss

Invest.-Projekt(fein)

Projekt-impuls

Grundlag.-ermittlung

Vor-Pl.

Ent-wurfspl.

Ge-nehm.

Ausfüh-rungsplan.

Vergabe Ausführung AbnahmeObjektbetr.

+ Doku..Abschluss

Projekte sind einmalig in der Gesamtheit der Bedingungen. Sie unterscheiden sich voneinander. Aller-dings sind auch wiederkehrende Muster identifizierbar, die die Basis von Vorgehensmodellen bilden.

1.5 Vorgehensmodelle

Vorgehensmodelle synthetisieren „Best PM Practice“ und bieten verschiedene Vorteile:

Vorgehensmodelle I standardisieren die PM-Arbeit, da Begriffe und Verfahren definiert und vorge-geben werden. Was genau unterscheidet z. B. ein Grobkonzept von einem Feinkonzept? Wie werden sie wann von wem erstellt und geprüft? Was folgt als nächstes?Vorgehensmodelle I erleichtern die PM-Arbeit, da Lösungsmuster (z. B. Phasen) vorgegeben wer-den. Vorgehensmodelle I verbessern die PM-Arbeit, da Vollständigkeit (z. B. mittels Checklisten) und Güte (z. B. mittels Indikatoren) überprüfbar werden.Vorgehensmodelle machen Projekte in einer Projektlandschaft I vergleichbar, da diese aufgrund einheitlicher Muster im Projektportfolio abbildbar werden.

Zu unterscheiden sind einerseits spezifische Vorgehensmodelle und andererseits übergreifende Vorgehensmodelle.

Spezifische Vorgehensmodelle sind Modelle, die für bestimmte Branchen, Projektarten, Projektge-genstände und Projektgrößen entwickelt wurden. Für IT-Projekte sind dies u. a. das V-Modell XT sowie HERMES. Eine über 800-Seiten mächtige Dokumentation zum V-Modell XT sowie entsprechende Werk-zeuge sind kostenfrei per Download zu erhalten (http://www.cio.bund.de). Handbücher und Hilfsmittel zu HERMES stehen ebenfalls kostenfrei zum Download zur Verfügung (http://www.hermes.admin.ch). Im Vertiefungskapitel „Projektphasen“ ist das HERMES-Modell im Überblick beschrieben. Vorgehens-modelle wurden auch für andere Projektarten und Projektgegenstände entwickelt. In der VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ ist ein Modell für die Mechatronik ausge-arbeitet. Pate hierfür war das V-Modell (VDI, 2004). Für die Entwicklung von Mehrkörpersystemen hat Isermann et al. ein Modell entwickelt (Isermann u. a., 2002). Ein Vorgehensmodell für die Entwicklung integrierter mechanisch-elektronischer Baugruppen wurde im Verbundprojekt INERELA erarbeitet

1.11

Projektphasen


(Gausemeier und Feldmann, 2006). Ein Vorgehensmodell für Organisationsprojekte („Organisationsun-tersuchungen und Personalbedarfsermittlung“), die den Zweck verfolgen, Optimierungskonzepte für die Aufgabenerfüllung zu erarbeiten, hat das Bundesministerium des Inneren mit Unterstützung der REFA (Verband für Arbeitsgestaltung, Betriebsorganisation und Unternehmensentwicklung e.V.) ver-öffentlicht. Das über 500-Seiten umfassende Handbuch steht frei zum Download zur Verfügung (http://www.orghandbuch.de). Die Liste der Vorgehensmodelle ließe sich fortsetzen. Das Problem ist in der Zwischenzeit nicht das Angebot, sondern die Auswahl eines angemessenen Modells. Übergreifende Vorgehensmodelle haben einen anderen Fokus: Sie sind für unterschiedliche Projekte unabhängig von der Branche, der Projektart oder vom Projektgegenstand geeignet. Teilweise bestehen unterschiedliche Versionen für eher kleinere oder größere Projekte. Eine solche Adaptionsoption bietet beispielsweise das Prozessmodell der DIN 69901-2:2009 (vgl. hierzu Kapitel 1.00). Weitere Vorgehensmodelle mit ei-nem übergreifenden Fokus sind PRINCE2 von OGC und PMBOK von PMI.

Beide Modellklassen, spezifisch und übergreifend, bieten eine Vielfalt an Vorlagen, die an die Unter-nehmensbedingungen anzupassen sind, was zur Entwicklung unternehmensspezifischer Vorge-hensmodelle führt. In der Regel ist zudem nur ein Vorgehensmodell nicht ausreichend: Externe Kun-den-Entwicklungsprojekte stellen z. B. andere Anforderungen an das Projektmanagement als interne Organisationsprojekte.

Vorgehensmodell-Bausteine: Was beinhalten diese eigentlich? Vorgehensmodelle legen oftmals ein bestimmtes (1) Phasenmodell mit (2) Meilensteinen fest, benennen (3) Hauptaktivitäten je Pha-sen, oftmals auch detaillierte (4) Aktivitäten, zudem (5) Regeln für die Abarbeitung der Aktivitäten sowie den Umgang mit Ergebnissen, definieren notwendige (6) Meilensteinergebnisse, geben ggf. be-stimmte (7) Methoden und Werkzeuge vor, stellen (8) Arbeitsmittel (wie Checklisten, Formulare, Standardsvorlagen) zur Verfügung, bieten zudem Standards für die Projektorganisation mittels (9) Rollenbeschreibungen (welche Rollen gibt es im Projekt, was sind deren Rechte, Pflichten und Befug-nisse) sowie ggf. weitere (10) Zusatzinformationen (z. B. summarische Angaben zu Phasenkosten oder dem Ressourcenbedarf). Vorgehensmodelle sagen, was, wie, wann, von wem & womit zu tun ist.

Die Entwicklung eines unternehmensspezifischen Vorgehensmodells könnte wie folgt ablaufen:

Kategorisierung der Projektlandschaft1. auf Basis von Erfahrungswerten nach z. B. Projektarten (z. B. intern / extern) und Projektgrößen (z. B. A-Projekte, B-Projekte, C-Projekte). Die Kunst hierbei ist, dass ausreichend spezifische Klassen abgegrenzt werden, damit die Projekte nach dem gleichen Muster abgearbeitet werden können und gleichzeitig hinreichend große Klassen gebildet werden, damit nicht jedes Projekt einen eigenen Standard bildet.Definition eines Standardphasenmodells mit Meilensteinen. 2. Die Kunst hierbei ist, dass rein se-quentielle Modell zwar leicht definierbar sind, diese jedoch der Realität von Projekten nicht immer gerecht werden, weshalb z. B. Schleifen (siehe Kapitel 2, unten) oder ähnliche Formen der Flexibili-sierung eingeplant und erlaubt werden sollten.Definition von Projektmanagement-Prozessen je Phase.3. Die Kunst hierbei ist das richtige Maß der Granularität zu finden. Werden zunächst Prozesse für große A-Projekte definiert, können diese anschließend abgespeckt werden für kleinere B- und C-Projekte. Das Prozessmodell der DIN 69901-2:2009 stellt hierfür Optionen zur Verfügung, die unternehmensspezifisch anpassbar sind.Definition von Methoden und Werkzeugen je PM-Prozess sowie Entwicklung von Arbeitsmit-4. teln. Definiert werden sollte nicht der Maximal-, sondern der Minimalstandard. Dieser kann mit wachsendem Reifegrad und Erfahrung mit dem Vorgehensmodell schrittweise angehoben werden.Definition von Rollenprofilen5. mit Pflichten, Verantwortungen, Rechten und Befugnissen.Sammlung von Daten, Entwicklung von Kennzahlen sowie schrittweise Optimierung. 6. Das Lernen aus Projekten bzw. die Auswertung der Erfahrung und Umsetzung dieser in Kennzahlen ist notwendig, um Zusatzinformationen gernerieren zu können. Hier zeigt sich der Mehrwert der Stan-dardisierung durch Vorgehensmodelle sehr deutlich.

Projektphasen

1.11


Die Entwicklung eines unternehmensspezifischen Vorgehensmodells wird einfacher, wenn ein idealty-pisches spezifisches oder übergreifendes Vorgehensmodell als Vorlage verwendet wird. Die Auswahl des geeigenten Modells könnte z. B. mittels einer Nutzwerkanalyse und folgender Kriterien erfolgen:

Konsistenz: I Ist das Modell logisch aufgebaut und plausibel?Akzeptanz: I Bietet das Modell ein gemeinsames Verständnis für alle Beteiligten? Ist das Modell leicht verständlich und nachvollziehbar?Aufwand: I Wie hoch ist der Aufwand zur Anpassung?Nutzen: I Sind die wichtigen, im weiteren Projektverlauf erforderlichen Entscheidungen erkennbar? Welcher konkrete Gewinn (Zeitersparnis, Qualitätssicherung, Reputation) entsteht durch die Anwen-dung des Modells?Verbreitungsgrad: I Welche und wie viele Unternehmen in der gleichen Branche greifen ebenfalls auf dieses Vorgehensmodell zurück?

1.6 Lebenszyklusmodelle

Eine Ergänzung der Projektphasenmodelle um den Aspekt der Projektergebnisse, deren Nutzung und deren Lebensdauer und ggf. die Einleitung eines neuen Projekts, um die genutzten Projektergebnisse durch neue Ergebnisse abzulösen, führt zu Lebenszyklusmodellen als Variante der rein projektbezoge-nen Phasenmodelle. In den Lebenszyklusmodellen folgen auf das „klassische“ Projektende, den Projekt-abschluss, die Inbetriebnahme, eine oder mehrere weitere Phasen, zunächst jedoch die Nutzungsphase, die dann meistens keinen Bezug mehr zu den ursprünglichen Projektverantwortlichen hat. Die Laufzeit der Nutzungsphase ist in der Regel mehr- bzw. sogar vieljährig und mündet am Ende der Laufzeit in eine Entscheidung über eine erneute Projektierung. Die Nutzungsphase leitet zumindest die Phase der Au-ßerbetriebnahme noch ein, um anschließend den Zyklus auf anderem Ergebnisniveau wieder von vorne beginnen zu lassen. Insbesondere an der Laufzeit von Kraftwerken oder der Lebenszeit von Produkti-onsbetrieben wird deutlich, dass eine Orientierung innerhalb eines einzigen Phasenmodells aufgrund der jeweiligen Phasendauer auch problematisch sein kann. Hilfreich ist allerdings, die Lebensphasen als Orientierung zu verstehen für notwendige Vorleistungen im Projekt z. B. für eine spätere Außerbe-triebnahme oder Stilllegung eines Projektergebnisses. Mit der Sicht auf den Lebenszyklus bzw. Lebens-weg wird das spätere Projekt „Außerbetriebnahme” oder „Stilllegung” bereits mit dem Abschluss der Realisierung angemessen dokumentiert vorbereitet. Die künftig einmal verantwortliche Projektleitung weiß auch 25 Jahre später, eine gute Vorleistung ihres Vorgängers zu schätzen. Bei kürzeren Projekt-lebensdauern kann demgegenüber sogar eine durchgängige Projektverantwortung sinnvoll sein. Dies ist z. B. der Fall bei der Fertigung von Produktchargen, die von der Auftragserteilung über Planung, Entwicklung und Produktion bis zum Abverkauf im Markt und bis zum Ablauf der Garantiezeit für die letzten verkauften Exemplare eine Gesamtdurchlaufzeit von nur 3-4 Jahren haben. Dies trifft u. a. auf die ganzen Aktionswaren zu, wie sie von Kaffeeröstern bis hin zu etablierten Handelsketten regelmä-ßig in den Markt gebracht werden.

1.11

Projektphasen


2 Flexibilisierung

Die in Kapitel 1 dargestellten Phasenmodelle weisen eine sequenzielle Struktur auf: Eine Phase folgt der anderen und Meilensteine trennen Phasen. Diese Logik ist nicht immer realistisch und angemessen und führt oftmals zu zeitlichen Verzögerungen.

2.1 Phasenübergänge und Meilensteine

Das „Reinschleichen“ in eine nächste Projektphase oder das „Rausschleichen“ aus einer Projektphase ist zwar immer wieder gelebter Alltag, wird dadurch, dass es praktiziert wird, im Grundsatz nicht besser. Dass es Situationen im Projektverlauf gibt, die parallele Projektphasen erfordern oder ermög-lichen und dass Überlappungen im Phasenübergang sinnvoll sein können, ist unbestritten. Mit der Ori-entierung an einem Phasenplan wird mit dem Projekterstauftrag und der zu beginnenden konkreten Projektentwicklung allerdings die Möglichkeit geboten, mit dem Auftraggeber gemeinsam zu planen, wann im Projektverlauf Entscheidungen zu treffen sind über die Fortsetzung oder den Abbruch des Projekts. In einem solchen Projekt kann es dennoch durchaus sinnvoll sein, dass Phasen überlappen. Eine komplexe Umweltverträglichkeitsprüfung kann z. B. an einem Standort noch nicht abgeschlos-sen sein, während an anderer Stelle bereits Baumaßnahmen begonnen haben, die „den Sachzwängen geschuldet“ sind, um das gesamte Vorhaben innerhalb des begrenzten verfügbaren Zeitrahmens, z. B. aus Gründen des Haushaltsrechts, abzuschließen. Eine noch weitergehende Variante der Phasenüber-schneidung ist insbesondere in der Software-Entwicklung die Parallelisierung von z. B. Planungs- und Realisierungsphase zur Verkürzung der Entwicklungszeiten. Spektakuläre Konsequenzen sind aller-dings auch fertig gestellte, aber nicht nutzbare Investitionsruinen. In den sogenannten „Schwarzbü-chern“ sind derartige Beispiele dokumentiert.

Ein Meilenstein wird in der DIN 69900:2009 definiert als „Schlüsselereignis“ bzw. als „Ereignis beson-derer Bedeutung“. Meilensteine besitzen Flexibilisierungspotentiale: Zunächst gilt es, die (1) Funktion eines Meilensteins zu klären (Liefergegenstände/Zwischenergebnisse, Prüfung, Entscheidung, Pha-senübergang). Meilensteine sind sodann zu operationalisieren; es sind Leistungskriterien sowie deren Ausprägung zu definieren. Die Terminierung ist hierbei ein nachgelagertes Kriterium! Ein typischer Fehler ist, dass Meilensteine zu früh terminiert werden. (2) Als Definitionen können Mindeststandards definiert werden sowie (3) Fristen zur Nacharbeit. (4) Phasenübergänge können automatisiert wer-den: Sobald der Phasen-Abschluss erreicht ist, startet die nächste Phase (Kombination von Phasen-Abschluss und Phasen-Freigabe). (5) Errechnete (sachlich-logische) und gewünschte (verhandelbare) Meilensteintermine sind zu unterscheiden. Realitäten sind oftmals eine Frage der Priorisierung.

Sinnvoll sind einerseits Phasenüberlappungen und eine Parallelisierung von Phasen, um die Flexibilität zu erhöhen. Sinnvoll ist andererseits auch, definitive Entscheidungspunkte zu vereinbaren, an denen das Projekt auf dem Prüfstand steht (siehe oben: Quality Gates).

2.2 Modellfamilien

In Anlehnung an Bunse und von Knethen (2008) werden nachfolgend drei Modellfamilien unterschie-den, die das Problem „standardisierte Flexibilität“ bzw. „flexible Standardisierung“ unterschiedlich lösen. Die Modellfamilien entstammen der Software-Entwicklung. Ziel dieses Kapitels ist es allerdings nicht, SE-Vorgehensmodelle zu beschreiben, sondern verschiedene Möglichkeiten der Flexibilisierung aufzuzeigen. Im Vertiefungskapitel Projektphasen wird der Ansatz „Agiles Projektmanagement“ ge-sondert beschrieben, weshalb dieser nachfolgend nicht weiter ausgeführt wird. Die drei Modellfamili-en sind:

Projektphasen

1.11


Sequentielle Modelle: I Zu diese Kategorie zählen Phasen-, Wasserfall- und Schleifenmodelle.Wiederholende Modelle: I Zu dieser Modellklasse zählen die inkrementellen, iterativen, rekursiven und evolutionären Modelle.Wiederverwendende Modelle: I Modelle dieser Kategorie sind darauf ausgerichtet, bestehende Module zu recyklen sowie in der Entwicklung auf die erneute Verwendbarkeit hin zu arbeiten.

Sequentielle Modelle

Zu dieser Modellkategorie zählen sequentielle Phasenmodelle, die den Übergang in die nächste Phase davon abhängig machen, dass alle Aktivitäten einer Phase vollständig abgeschlossen sind und alle Ergeb-nisse vollständig vorliegen. Phasenrückschritte stellen Ausnahmen dar. Die Ergebnisse, z. B. Entwurfs-dokumente, einer Phasen bilden die Voraussetzung für die Arbeiten in der nächsten Phase und werden dort weiterverarbeitet. Wasserfall- bzw. Schleifenmodelle folgen ebenfalls einer sequentiellen Logik. Sie erlauben allerdings kontrollierte Iterationen, um Aktivitäten einer Vorphase erneut durchzuführen. Notwendig sind Rückschritte, z. B. um Fehler einer vorangehenden Phase zu korrigieren oder um geän-derte Anforderungen zu berücksichtigen. Welche Rückschritte erlaubt sind, ist vom jeweiligen Modell abhängig. Dies kann nur die letzte Phase sein, wie beim Wasserfallmodell, oder auch eine weit frühe-re Phase, wie beim Schleifenmodell. Eine weitere Form der Flexibilisierung ist die Verwendung von Prototypen oder Pilotanwendungen in sequentiellen Modellen. An bestimmten Zeitpunkten ist die Entwicklung von Prototypen (vereinfachte oder eingeschränkt funktionsfähige Varianten) oder Pilot-anwendungen (Anwendungen in einem begrenzten Rahmen) geplant. Kontrollierte Rückschritte bzw. Wiederholungen der Aktivitäten einer Phase sind an diesen Zeitpunkten bewusst eingeplant, um die Erfahrung mit dem Prototyp / der Pilotanwendung verwerten zu können. In Abbildung 1.11a-5 sind die verschiedenen Varianten dargestellt: Linear, mit Phasenrückschritten, mit Schleifen und Prototypen.

Abbildung 1.11a-5: Sequentielle Modellfamilie Quelle: In Anlehnung an Bunse & von Knethen, 2008: 8

Sequentielle Modell sind gut einsetzbar, wenn Erfahrung besteht hinsichtlich der geplanten Entwick-lung und wenn die Anforderungen stabil sind. Ein Vorteil ist, dass kein umfangreiches Konfigurations-management notwendig ist, da nur wenige Versionsänderungen anfallen bzw. möglich sind. Nachteilig ist jedoch, dass an den Phasenübergängen zeitliche Verzögerungen entstehen können, fertige Produkte erst sehr spät entstehen (außer bei Pilotanwendungen in z. B. OE-Projekten), was bei zeitlichen Ver-zögerungen dazu führen kann, dass bei fixen Endterminen kein fertiges Produkt vorliegt. Wenn die Erfahrung gering ist, Anforderungen instabil oder unscharf sind und fixe Endtermine bestehen, sind streng-sequentielle ungeeignet. Für diese Fälle sind wiederholende Modelle besser geeignet.

1.11

Projektphasen


Wiederholende Modelle

Basisidee der wiederholenden Modelle ist, dass das Projekt nicht in sequentiellen Phasen (erst die voll-ständige Analyse, dann der vollständige Entwurf, dann die vollständige Implementierung, dann die vollständige Integration usw.), sondern in Inkrementen abgearbeitet wird. Ein Inkrement bildet eine Teilmenge der Gesamtanforderungen. Diese werden abgearbeitet (Analyse, Entwurf, Implementierung usw.) bevor eine erweiterte Teilmenge abgearbeitet (erneut: Analyse, Entwurf, Implementierung usw.) wird. Das Produkt wächst mit jedem Inkrement (lat. incrementum = Wachstum). Der Vorteil ist, dass Erfahrung schrittweise aufgebaut und direkt gelernt wird, die Komplexität zunächst reduziert ist (und sich schrittweise erhöht), Teilprodukte bereits früh entstehen und schrittweise erweitert werden, was bei Terminengpässen zumindest Teillieferungen ermöglicht. In Abbildung 1.11a-6 ist diese Grundidee illustriert für drei Inkremente.

Abbildung 1.11a-6: Inkremente als Grundidee wiederholender Modelle Quelle: Bunse & von Knethen, 2008: 12

Wiederholende Modelle sind geeignet, wenn Anforderungen unscharf oder instabil sind und die Erfah-rung gering ist. In diesem Fall könnte z. B. mit den sichersten Anforderungen begonnen werden, um dann mit wachsender Erfahrung Sicherheit zu gewinnen. Notwendig ist jedoch, dass die Anforderungen in Teilmengen untergliederbar und diese möglichst wenig voneinander abhängig sind. Im ungünsti-gen Fall, insbesondere bei vielen Abhängigkeiten, kann es passieren, dass geänderte Anforderungen in späteren Inkrementen eine Überarbeitung bereits fertig gestellter Ergebnisse notwendig macht. Not-wendig ist zudem ein gutes Versions- und Konfigurationsmanagement, da nicht nur von Inkrement zu Inkrement, sondern auch innerhalb eines Inkrements durch Rückschritte (wie bei den sequentiellen Modellen) verschiedene Versionen entstehen. Notwendig und sinnvoll ist zudem, mit dem Auftraggeber die abzuarbeitenden Inkremente zu priorisieren, damit im Fall einer Terminverzögerung, die wichtigen Funktionen zumindest realisiert sind.

Zu den wiederholenden Modellen zählen neben den inkrementellen Modellen die iterativen, rekursiven und evolutionären Modellen. Ein evolutionäres Modell von Boehm (1988) ist in Abbildung 1.11a-7 dar-gestellt.

Projektphasen

1.11


Abbildung 1.11a-7: Evolutionärer Ansatz als Beispiel eines wiederholenden Modells Quelle: Bunse & von Knethen, 2008: 13

Bruno Jenny merkt zu Recht an, dass eine aus dem Modell herausgetrennte und aufgebogene Spirale theoretisch ein sequentielles Modell bildet (Jenny, 2009: 146). Meilensteine könnten sodann den Pha-senübergang markieren zwischen „Plane nächste Phase“ und „Lege Ziele, Alternativen und Beschrän-kungen fest“. Das Modell wäre damit durchaus als Phasenplan in Balkenform mit Meilensteinen dar-stellbar.

Wiederverwendende Modelle

Wiederverwendende Modell sind darauf ausgerichtet, einerseits Ergebnisse aus abgeschlossenen Pro-jekten wiederzuverwenden und andererseits im Projekt darauf hinzuarbeiten, dass eigene Ergebnisse in anderen Projekten verwendbar sind. Vorteile sind u. a., dass auf Erfahrung zurück gegriffen werden kann und Prototypen schneller entwickelbar sind. Nachteilig kann sein, dass wiederverwendete Ergeb-nisse, wenn sie nicht ausreichend passend sind, die Komplexität erhöhen und zudem anzupassen sind. Erforderlich ist, wie bei den wiederholenden Modellen, dass ein umfangreiches Versions- und Konfi-gurationsmanagement im Projekt und projektübergreifend besteht, damit die Wiederverwendbarkeit von Projekt zu Projekt qualitätsgesichert möglich ist. Im Projekt sind Ergebnisse wiederum für andere Projekte aufzubereiten, was zusätzlichen Aufwand bedeutet (falls dies nicht eine spezielle Service-Ein-heit übernimmt). Zudem sind die Wiederverwendungskandidaten projektübergreifend zu verwalten. Wiederverwendende Modelle erfordern deshalb eine entsprechende Unternehmensstrategie sowie un-terstützende projektübergreifende Unternehmensprozesse. In Abbildung 1.11a-8 ist ein entsprechen-des Modell dargestellt.

1.11

Projektphasen


Abbildung 1.11a-8: Wiederverwendende Modelle Quelle: Bunse & von Knethen, 2008: 16

An dieser Stelle endet das Basiskapitel. Im Vertiefungskapitel werden das Vorgehensmodell HERMES sowie das Agile Projektmanagement dargestellt.

3 Fragen zur Wiederholung

1 Was sollte ein erster grober Phasenplan mindestens beinhalten? 2 Benennen Sie Beispiele projektartenspezifischer Phasenmodelle. 3 Worin bestehen Vorteile und Nachteile, wenn eine Phasenbetrachtung angewendet wird? 4 Was sind Gemeinsamkeiten und Unterschiede von Meilensteinen und Gates? 5 Worin bestehen Vorteil und Nachteile, wenn Vorgehensmodelle verwendet werden? 6 Wie sind spezfische und übergreifende Vorgehensmodelle unterscheidbar? 7 Welche Bausteine können Vorgehensmodelle (VM) beinhalten? 8 Wie würden Sie vorgehen, um ein unternehmensspezifisches VM zu entwickeln? 9 Welche Möglichkeiten bestehen zur Flexibilisierung von Phasenplänen?

2466 GPM | PM3 | Literaturverzeichnis | Band 1

BAN

D 1 Literaturverzeicnis

Dörrenberg, F. (2004). Phasen in internationalen Projekten. In H.-E. Hoffmann, Y. Schoper & C. J. Fitzsimons (Hrsg.), Internationales Projektmanagement. München: Beck-dtv.

Felske, P. (2003). Integrierte Projektsteuerung. In RKW (Rationalisierungs-Kuratorium der Deutschen Wirtschaft e.V.) & GPM (Deutsche Gesellschaft für Projektmanagement e.V.) (Hrsg.), Projektmanagement Fachmann. 7. Aufl. Eschborn: RKW-Verlag.

GPM Deutsche Gesellschaft für Projektmanagement e.V. (2008). ICB - IPMA Competence Baseline in der Fassung als Deutsche NCB 3.0. Nationale Competence Baseline der PM-ZERT, Zertifizierungsstelle der GPM. Nürnberg: GPM

IPMA International Project Management Association (Hrsg.) (2006). ICB (IPMA Competence Baseline). Version 3.0. Nijkerk (NL): IPMA.

Möller, T. & Dörrenberg, F. (2003). Projektmanagement-Repetitorium. München: Oldenbourg.

Motzel, E. (2006). Projektmanagement Lexikon. Begriffe der Projektwirtschaft von ABC-Analyse bis Zwei-Faktoren-Theo-rie. Weinheim: WILEY-VCH.

Patzak, G. & Rattay, G. (2004). Projektmanagement. Leitfaden zum Management von Projekten Projektportfolios und projektorientierten Unternehmen. 4., wesentlich überarb. und erg. Aufl. Wien: Linde.

Platz, J. (2003). Projektstart. In RKW (Rationalisierungs-Kuratorium der Deutschen Wirtschaft e.V.) & GPM (Deutsche Gesellschaft für Projektmanagement e.V.) (Hrsg.), Projektmanagement Fachmann. 7. Aufl. Eschborn: RKW-Verlag.

B Weiterführende Literatur

RKW (Rationalisierungs-Kuratorium der Deutschen Wirtschaft e.V.) & GPM (Deutsche Gesellschaft für Projektmanage-ment e.V.) (Hrsg.). Projektmanagement Fachmann. 7., überarb. u. aktual. Aufl. Eschborn: RKW-Verlag.

1.11a Projektphasen

A Verwendete Literatur

Bender, K. (2005). Systematisierung von Entwicklungsprozessen. In K. Bender (Hrsg.), Embedded Systems - qualitätsori-entierte Entwicklung (S. 21-50). Berlin: Springer.

Boehm, B.W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computers, Vol. 21, Nr. 5, S. 61-72.

Bunse, C. & Knethen, von (2008). Vorgehensmodelle kompakt. 2. Auflage. Heidelberg: Spektrum Akademischer Verlag.

DIN 69901-2 (2009). Projektmanagement – Projektmanagementsysteme. Teil 2: Prozesse, Prozessmodell. Berlin: Beuth

Ebel, N. (2007). PRINCE2 Projektmanagement mit Methode. Grundlagenwissen und Vorbereitung für die Zertifizierungs-prüfungen. München: Addison-Wesley Verlag.

Eberle, R. & Schmid, P. (2009). Altersgerechtes Automobil. Generische Fallstudie. Vorgehensmodell zur Entwicklung eines altersgerechten Automobils. In Fisch, J.H. & Roß, J.-M. (Hrsg.), Fallstudien zum Innovationsmanagement (S. 139-162). Wiesbaden: Gabler.

Ferber, P., Schmitz, T. & Waibel, G. (2005). Integratives Vorgehensmodell für die methodische Veränderung von Unter-nehmenskulturen. In H. Österle, R. Winter & W. Brenner (Hrsg.), Business Engineering in der Praxis (S. 553-584). Berlin: Springer.

Gausemeier, J. & Feldmann, K. (2006). Integrative Entwicklung räumlicher elektronischer Baugruppen. München: Carl Hanser Verlag.

GPM Deutsche Gesellschaft für Projektmanagement (2008). ICB - IPMA Competence Baseline in der Fassung als Deut-sche NCB 3.0. National Competence Baseline der PM-ZERT, Zertifizierungsstelle der GPM. Nürnberg: GPM.

HOAI (2009). Verordnung über die Honorare für Architekten- und Ingenieurleistungen (Honorarordnung für Architekten und Ingenieure – HOAI), vom 11. August 2009, Bundesgesetzblatt Jahrgang 2009 Teil I Nr. 53, ausgegeben zu Bonn am 17. August 2009.

IPMA International Project Management Association (2006). ICB – IPMA Competence Baseline. Version 3.0. Nijkerk: IPMA.

Isermann, R., Breuer, B. & Hartnagel, H.L. (Hrsg.) ( 2002). Mechatronische Systeme für den Maschinenbau - Ergebnisse aus dem Sonderforschungsbereich 241 „Integrierte mechanisch elektronische Systeme für den Maschinenbau (IMES)“. Weinheim: Wiley-VCH Verlag.

Jenny, B. (2009). Projektmanagement. Das Wissen für den Profi. Zürich: vdf Hochschulverlag an der ETH Zürich.

GPM | PM3 | Literaturverzeichnis | Band 1 2467

BAN

D 1 Literaturverzeicnis

Kerzner, H. (2003). Projektmanagement. Ein systemorientierter Ansatz zur Planung und Steuerung.Bonn: mitp-Verlag.

Kühl, S., Strodtholz, P. & Taffertshofer, A. (Hrsg.) (2009): Handbuch Methoden der Organisationsforschung. Quantitative und Qualitative Methoden. Wiesbaden: VS Verlag für Sozialwissenschaften.

Lindemann, U. (2009). Methodische Entwicklung technischer Produkte. Methoden flexibel und situationsgerecht an-wenden. 3., korrigierte Auflage. Berlin: Springer-Verlag.

Oesterreich, B. & Weiss, C. (2008). APM – Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte. Heidel-berg: dpunkt.verlag.

SIA (2001). Leistungsmodell. Schweizer Ingenieur- und Architektenverein (SIA). Zürich. http://www.webnorm.ch

VDI (1993). VDI-Richtlinie 2221 – Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. VDI – Verlag, Düsseldorf

VDI (2004). VDI-Richtlinie 2206 - Entwicklungsmethodik für mechatronische Systeme. Berlin: Beuth Verlag.

1.11b Ablauf und Termine


DIN Deutsches Institut für Normung e.V. (Hrsg.): Projektmanagement-Normen.

DIN 69900 (2009). Projektmanagement – Netzplantechnik; Beschreibung und Begriffe. Berlin: Beuth Verlag.

DIN 69901-5 (2009). Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe. Berlin Beuth Verlag.

RKW (Rationalisierungs- Kuratorium der deutschen Wirtschaft e.V.) & GPM (Deutsche Gesellschaft für Projektmanage-ment e.V.) (Hrsg.) (1994). Projektmanagement Fachmann. 2. überarb. Aufl. Eschborn: RKW-Verlag.

Schelle, H., Ottmann, R. & Pfeiffer, A. (2005). ProjektManager. Nürnberg: GPM Deutsche Gesellschaft für Projektma-nagement e.V.


Groh, H. & Gutsch R. W. (Hrsg.) (1982). Netzplantechnik. Düsseldorf: VDI-Verlag.

Reschke, H., Schelle, H. & Schnopp, R. (Hrsg.) (1989). Handbuch Projektmanagement. Band 1 und 2. Köln: TÜV Media.

1.12 Ressourcen


Motzel, E. (2006). Projektmanagement-Lexikon. Begriffe Einsatzmittel bis Einsatzmittelvorrat. Weinheim: Wiley.

Scheuring, H. (2008). Der www-Schlüssel zum Projektmanagement. 4. Aufl. Zürich: Orell Füssli.


Campana, C. & Schott, E. (2002). Ressourcenmanagement in der Unternehmenspraxis. In Projekt Magazin, Ausgabe 22 / 2002. München: Berleb & Wolf-Berleb.

Ahlemann, F. (2007). Project Management Software Systems. Requirements, Selection Process and Produkts, 5th Editi-on. Würzbürg: Oxygon.

1.13 Kosten und Finanzmittel


Abell, D. F. & Hammond, J. S. (1979). Strategic Market Planning: Problems and Analytical Approaches. Englewood Cliffs: Prentice-Hall.

Bechler, K. J. & Lange, D. (2005). DIN Normen im Projektmanagement. Berlin: Beuth.

Gessler_Projektphasen_2010

Documents

Transcript of Gessler_Projektphasen_2010