PECO-PM-Basispräsentation, (C) Peterjohann … · Peterjohann Consulting Projektmanagement:...

Peterjohann Consulting Projektmanagement: Basispräsentation

1.83 – 17.09.2012 Seite 1 von 228

PM Basis

Zusammengestellt von H. Peterjohann Für eine mehrtägige Schulung Version 1.83 vom 17.09.2012

228 Seiten Alle Rechte vorbehalten. Reproduktion zum nicht-kommerziellen Gebrauch mit Quellenangabe

gestattet. Reproduktion – auch auszugsweise – zum kommerziellen Gebrauch sowie der Gebrauch für Vortragszwecke sind nur mit schriftlicher Bewilligung des Verfassers gestattet.

Projektmanagement

Eine Einführung (PM-Basispräsentation) Für Projektmanager und Projektmitarbeiter Stand: 09/2012

Sie finden diese und weitere Präsentationen unter (→ Klick): https://www.peterjohann-consulting.de/praesentationen

https://www.peterjohann-consulting.de/praesentationen



1.83 – 17.09.2012 Seite 2 von 228

PM Basis

Version Datum Autor Beschreibung Seiten Verteiler 1.80 13.03.2011 HP Erste komplette Version; Freigabe 220 Website HP 1.81 30.06.2011 HP Kleine Korrekturen 223 Website HP 1.82 10.01.2012 HP Anpassung an neues Layout 228 Website HP 1.83 17.09.2012 HP Optische Verbes., ISO 21500 228 Website HP

Überprüfung:

Version Datum Autor Beschreibung 2.00 Feb 2018 HP Komplett-Überprüfung und Erweiterung 2.10 31.12.2018 HP Überprüfung und Erweiterung

Änderungsvorhersage:

Version Datum Durch 1.80 13.03.2011 Andreas Braunmiller

Dokumentenhistorie

Vorwort


1.83 – 17.09.2012 Seite 3 von 228

PM Basis

• „Projekte“ macht jeder – ab einer bestimmten Größe sollten diese aber gemanagt werden

• Projektmanagement (kurz: PM) kann man nicht innerhalb einer (kurzen) Schulung lernen, man muss es „erleben“

• Es ist nicht sinnvoll, sich PM nur per Lehrbuch oder aus reiner Praxis anzueignen: Generell sollte man Schulungen zum Projektmanagement besuchen

• Es gibt eine Vielzahl von Kursen und Büchern zu diesem Thema, leider ebenso viele schlechte wie gute

• Ist dem Software(entwicklungs-)Projektmanagement übergeordnet (beide Disziplinen ergänzen sich)

• Diese Präsentation deckt die wesentlichen Aspekte des PMs ab und in erster Linie für Projekt-Einsteiger gedacht (und weniger für erfahrene Projektmanager)

• Man kann sich „unendlich lange“ mit dem Projektmanagement auseinandersetzen – letztlich zählt aber die Praxis (und die erzielten Erfolge)

• Nicht der Projektmanagement-Prozess ist nach außen sichtbar, sondern nur das Ergebnis

Vorab (1/3): Zum Projektmanagement

Vorwort


1.83 – 17.09.2012 Seite 4 von 228

PM Basis

• Diese Präsentation ist „für sich“ eigenständig, kann also ohne Sekundärquellen nachvollzogen werden

• Es wird hier eine Übersicht des Projektmanagements (PM) geliefert und daher kein Lehrbuch ersetzt

• Die Begriffe im Projektmanagement sind nicht immer eindeutig; im Zweifel werden hier „allgemein übliche“ Beschreibungen verwendet

• Die englischen Bezeichnungen werden dort, wo sie massiv Einzug gehalten haben, auch zusätzlich notiert

• Diese Präsentation verwendet eher Bilder als Texte, da sie nur einen Auszug aus den kompletten Schulungsunterlagen (des Autors) darstellt

• Checklisten, Leitfäden, Tipps & Tricks, Regeln, Best-Practices, Methoden- und Toolsammlungen für ein „vollständiges PM“ sind hier nur zum Teil enthalten

• Auf Literatur (Bücher) wird im Text in der Form „/Buch12/“ verwiesen; die Literaturliste findet sich im Anhang

• Weitere Präsentationen zu PM-Spezial- oder Einzelthemen sind auf der Website des Autors verfügbar

Vorab (2/3): Zu dieser Präsentation

Vorwort


1.83 – 17.09.2012 Seite 5 von 228

PM Basis

• Sie sind der Projektmanager (abgekürzt PjM, ein anderer Begriff ist Projektleiter) und tragen die komplette Verantwortung für das Projektergebnis

• Sie müssen als Projektmanager Ihre Projektmitarbeiter auch disziplinarisch führen • Das Projekt ist groß, so dass der Einsatz von Projektmanagement

(-methoden) notwendig ist und Sie „Fulltime-“Projektmanager sind • Das Projekt ist nicht trivial, so dass Sie auch „Randthemen“ wie Qualitäts- oder

Risikomanagement kennen sollten

Vorab (3/3): Zu Ihrer Rolle in der Präsentation

Vorwort

Zielgruppe: Projektmanager und Projektmitarbeiter Voraussetzungen: Erste Erfahrungen in Projekten Schwierigkeitsgrad: Gering bis mittel


1.83 – 17.09.2012 Seite 6 von 228

PM Basis

Auf folgende Verbände und Normen wird in dieser Präsentation verwiesen: • DIN: Deutsche Normenreihe 69900:2009 ff. „Projektmanagement“; Buch

hierzu /DIN09/ • GPM: Deutsche Gesellschaft für Projektmanagement; Buch hierzu

„Kompetenzbasiertes Projektmanagement (PM3)“ /GPM12/ • PMI: Project Management Institute; Buch hierzu „PMBOK Guide“ /PBG08/

(oder das deutsche Pendant /PBG08-d/) Sollten unterschiedliche Beschreibungen möglich sein, so wird prinzipiell die PMI-Darstellung vorgezogen. Als Nachschlagewerke im Internet werden benutzt: • ProjektMagazin: https://www.projektmagazin.de /PMag/ • Deutsche Wikipedia: https://de.wikipedia.org /Wiki-d/

Anmerkung: Die hier genannten Literaturstellen und Links weisen ein fettgedrucktes Kürzel auf, da sie besonders häufig zitiert werden!

Oft zitierte Literatur

Vorwort

http://www.projektmagazin.de/



1.83 – 17.09.2012 Seite 7 von 228

PM Basis

Übung Eine Übung beschreibt eine Aufgabe, die durch den Leser selbst oder besser in einer (Klein-)Gruppe gelöst werden sollte. Es wird immer eine Dauer mitangegeben, d.h. eine Zeitvorgabe, wie lange die Bearbeitung benötigen sollte. Musterlösungen existieren im Allgemeinen hierfür nicht.

Fragen Kontrollfragen, die zur Überprüfung des Lernziels / des Gelernten dienen und daher individuell beantwortbar sein sollten. Musterlösungen existieren, werden aber hier nicht veröffentlicht.

Tipps Empfehlungen und Ratschläge – zumeist unmittelbar aus der Praxis kommend.

Check-liste

Checklisten dienen zur Überprüfung, ob „alles richtig gemacht wird“ (in konkreten Projekten). Es werden nur kurze Checklisten verwendet; Langfassungen werden hier nicht veröffentlicht.

Einige Folien sind besonders herausgehoben, da sie vom Leser / Teilnehmer besondere Aktivitäten erwarten; folgende vier Sonderfolien gibt es:

Übungen, Fragen, Tipps und Checklisten

Vorwort


1.83 – 17.09.2012 Seite 8 von 228

PM Basis

Glie

deru

ng

Teil I: Grundlagen 1. Einleitung und Grundlagen 11 – 32 2. Projektziele 33 – 39 3. Stakeholdermanagement 40 – 53 4. Projektorganisation und Rollen im Projekt 54 – 74 5. Projektstart und Projektdokumente 75 – 88 Teil II: Planen, Verfolgen, Abschließen 6. Planungen im Projekt 90 – 132 7. Controlling und Berichtswesen 133 – 144 8. Projektabschluss 145 – 155

Teile I-II

Gliederung (1/2)

Seite 10-155


1.83 – 17.09.2012 Seite 9 von 228

PM Basis

Glie

deru

ng

Teil III: Teambuilding, Kommunikation, Qualität, Risiko 9. Teambuilding 157 – 162 10. Kommunikation 163 – 171 11. Qualitätsmanagement 172 – 184 12. Risikomanagement 185 – 199 Teil IV: Anhang A. Literatur, Weblinks, Sprüche und Glossar 201 – 214 B. Normen, Zertifikate und Verbände 215 – 218 C. PM in der SW-Entwicklung, Reifegradmodelle 219 – 225 D. Weitere Präsentationen, Kontakt zum Autor 226 – 228

Teile III-IV

Gliederung (2/2)

Seite 156-228


1.83 – 17.09.2012 Seite 10 von 228

PM Basis

Teil I Te

il I

Seite 10-88

Teil I: Grundlagen

Kapitel 1 Einleitung und Grundlagen Kapitel 2 Projektziele Kapitel 3 Stakeholdermanagement Kapitel 4 Projektorganisation und Rollen im Projekt Kapitel 5 Projektstart und Projektdokumente


1.83 – 17.09.2012 Seite 11 von 228

PM Basis

Kapitel 1: Einleitung und Grundlagen

Kapi

tel 1

• Was ist ein Projekt? (Definition, Beispiele, Abgrenzungen,

Ziele, Größen, Kategorien, Arten, Verlauf) • Was ist Projektmanagement? (Definition, Ziele, Aufgaben) • Das magische Dreieck des Projektmanagements • Projektmisserfolg (Ursachen, Vorab-Prüfschema) • Projektphasen (Definition, Idealisierter Überblick,

Minimalmodell, Weitere Unterteilung nach PMI, Weitere Modelle)

• Der Meilensteinplan • Fragen zum Kapitel

Seite 11-32

Teil I

1. 2. 3. Einleitung und Grundlagen I. 4. 5.


1.83 – 17.09.2012 Seite 12 von 228

PM Basis

Ein Projekt … • hat einen definierten Beginn und ein definiertes Ende, ist also zeitlich

befristet. • hat eine besondere, auf das Vorhaben abgestimmte Organisation. • (ist interdisziplinär). • hat begrenzte Ressourcen. • besitzt eine Aufgabenstellung mit Risiko und einer gewissen Einmaligkeit. • hat mindestens einen Projektmanager (PjM), einen Projektplan und einen

Projektmitarbeiter (MA).

Nach DIN 69901-5:2009 /DIN09/ gilt: „Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in Ihrer Gesamtheit gekennzeichnet ist, wie z.B. … • Zielvorgabe, • zeitliche, finanzielle, personelle und andere Begrenzungen • projektspezifische Organisation.“

Was ist ein Projekt (1/8)? Definition



1.83 – 17.09.2012 Seite 13 von 228

PM Basis

Ein Projekt ist beispielsweise … • ein Hausbau (insofern es kein Fertighaus ist), • das Erstellen einer Website, • der Umbau oder Aufbau einer Firma.

Ein „Projekt“ ist kein „Prozess“: Nicht alles, was Menschen geplant und organisiert machen, ist ein Projekt. Die Buchhaltung in einem Unternehmen sollte kein Projekt sein, sondern eine fortlaufender Arbeitsablauf („Prozess“), der sich beständig wiederholt. Die Einführung einer neuen Methode der Buchhaltung inklusive der dazugehörigen Software stellt allerdings ein Projekt dar, denn sie … • ist zeitlich begrenzt – irgendwann ist die Buchhaltung umgestellt. • ist einmalig – die Umstellung der Buchhaltung wird in dieser Form im Unternehmen

nie wieder durchgeführt. • führt zur Schaffung eines Produktes oder einer Dienstleistung – es sollte zumindest

festgelegt sein, was am Ende herauskommen soll.

Was ist ein Projekt (2/8)? Beispiele



1.83 – 17.09.2012 Seite 14 von 228

PM Basis

Was ist ein Projekt (3/8)? Abgrenzungen


… sind alle laufenden Aufgaben und Tätigkeiten, die nicht den Anspruch der Einmaligkeit erheben und nicht an bestimmte Endtermine im Sinne

der Projektterminologie gebunden sind.

Bezeichnung

Projekte

Vorhaben

Linienmaßnahmen

Regelprozesse

Beschreibung

… sind Aufgaben die eindeutig einem Geschäftsbereich, einer Abteilung, einem Ressort zuordbar sind. Für Linienmaßnahmen ist es nicht

notwendig, eine eigene Organisation aufzubauen, sondern Entscheidungen werden durch bestehende Hierarchien im Rahmen

verfügbarer Jahresbudgets getroffen.… haben bereits große Ähnlichkeiten mit Projekten. Wie diese tragen sie in der Regel das Merkmal „Einmaligkeit“ und wollen klar umrissene Ziele erreichen. Vorhaben benötigen keine eigene Organisation und sind daher

erst einmal Linientätigkeiten. Vielfach werden in der Praxis ressortübergreifende Vorhaben schon als Projekte bezeichnet.

Ob ein Vorhaben als Projekt durchgeführt werden soll, entscheidet sich erst nach Abwägung bestimmter Entscheidungskriterien, die mehrheitlich

in hohem Maß erfüllt sein müssen. /Lessel12/


1.83 – 17.09.2012 Seite 15 von 228

PM Basis

Was ist ein Projekt (4/8)? Ziele


Unternehmens-ziele

Sachziele Abwicklungsziele• Termine• Aufwand / Kosten• Transparenz• Ablauf• Ressourceneinsatz

• Funktion• Leistung• Qualität• Eigenschaften

• Erwartungen an das Projekt• Gewinnmarge• Ressourcennutzung• Stückzahlen• Marktstrategie


1.83 – 17.09.2012 Seite 16 von 228

PM Basis

Was ist ein Projekt (5/8)? Größen

Diese Unterteilung ist nicht „trennscharf“ und gibt nur einen Anhaltspunkt, wie Projekte einzuordnen sind.


Kleines Projekt(„C-Projekt“)

Mittleres Projekt(„B-Projekt“)

Großes Projekt(„A-Projekt“)

Dauer 6-12 Monate 6-24 Monate über 12 Monate

Teamgröße 2-6 Mitarbeiter 4-12 Mitarbeiter über 6 Mitarbeiter

Dokumentation Verzeichnisstruktur ProjektplanVerzeichnisstruktur

Meetings Projektteam-Meeting Projektteam-MeetingProjektteam-MeetingsTeilprojektmeetings

Fachtreffen

Review-Gremium nicht unbedingtnotwendig erforderlich unbedingt erforderlich -

mindest. 1*/Monat

Bedeutung für das Unternehmen gering mittel hoch

ProjektplanVerzeichnisstruktur

Finanzieller Umfang gering mittel hoch

Komplexität/Risiko gering mittel hoch


1.83 – 17.09.2012 Seite 17 von 228

PM Basis

Was ist ein Projekt (6/8)? Kategorien


komplexeStandardprojekte

Routineprojekte

Pionierprojekte

Potenzialprojekte

sozialeKomplexität

hoch: bereichsübergreifend, interdisziplinär, komplizierte Wirkungszusammenhänge

gering: hauptsächlich Zusammenarbeit im Fachgebiet, einfache Wirkungszusammenhängekleines Risiko

geschlossen: klare Aufgabenstellung

offen: Aufgabenstellung mit vielen inhaltlichen und vorgehens-

mäßigen Möglichkeiten

Aufgaben-stellung


1.83 – 17.09.2012 Seite 18 von 228

PM Basis

Unterteilung nach DIN 69901-5:2009

Was ist ein Projekt (7/8)? Arten


• Bau eines Gebäudes• Einrichtung einer neuen

Fertigung• Installation eines PC-

Netzwerkes• Anschaffung einer

komplexen Anlage• ...

• Entwicklung eines neuen Produktes (z.B. Autos)

• Entwicklung eines Expertensystems

• Entwicklung eines Softwaresystems

• Entwicklung eines Medikaments

• ...

• Einführung eines neuen Vertriebssystems

• Einführung eines neuen Marketingkonzepts

• Vergrößerung des Marktanteils

• Einführung einer neuen Organisationsform

• Organisation einer Firmenfeier

• Zertifizierung nach einer Norm

• ...

Investitionsprojekte Forschungs-& Entwicklungs-Projekte

Organisations-und IT-Projekte


1.83 – 17.09.2012 Seite 19 von 228

PM Basis

Es gilt die 10er-Regel: Die Umsetzung von Änderungen werden pro Projektphase (die später erläutert werden) um den Faktor 10 teurer!

Was ist ein Projekt (8/8)? Verlauf


Projektdauer

Einflussmöglichkeit(der Stakeholder)

Kosten pro Änderung/

Fehler


1.83 – 17.09.2012 Seite 20 von 228

PM Basis

Nach DIN 69901-5:2009 /DIN09/ ist Projektmanagement die „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.“

Projektmanagement = Projekt + Management

Was ist Projektmanagement (1/3)? Definition


• einmaliger Ablauf• komplexe Struktur• festgelegtes Ziel• vorgegebener

Abschlusstermin• begrenzte Ressourcen

• Planung• Koordinierung• Überwachung• Steuerung

Projekt Management

Projektmanagement

Inspiration OrdnungImprovisation Routine


1.83 – 17.09.2012 Seite 21 von 228

PM Basis

Die übergeordneten Ziele des Projektmanagements sind: • Zufriedene Auftraggeber oder Kunden • Erreichung oder Übertreffen der (wirtschaftlichen) Projektziele • Kalkulierbare, für alle Beteiligten tragbare Projektziele

Weitere Ziele: • Förderung professioneller Projekt- und Teamarbeit • PM erhöht die Wahrscheinlichkeit, dass ein Projekt zum Erfolg wird

Verwandte Disziplinen: • Risikomanagement (alle Tätigkeiten beim PM zielen darauf ab, das Risiko zu

reduzieren) • Qualitätsmanagement (Qualität in allen Teilbereichen ist ebenfalls Ziel des

PMs) • Requirements Engineering (durch RE ist es möglich, die Anforderungen zu

ermitteln und zu verwalten; PM-Methoden werden auch beim RE verwendet)

Was ist Projektmanagement (2/3)? Ziele



1.83 – 17.09.2012 Seite 22 von 228

PM Basis

Was ist Projektmanagement (3/3)? Aufgaben


Aufbau-organisation

Projektziele

Ablauf-organisation

Projekt-planung

Projekt-steuerung

Projekt-führung

Aufbauorganisation Ablauforganisation

ProjektsteuerungProjektführung

Projektplanung

Projektziele

Aufbau einer zeitlich befristeten Projektorganisation

mit personifizierten Verantwortungen

Bestimmung des Projektablaufs mit

eindeutigen Ergebnissen

Planung von (realistischen und abgestimmten) Leistungen,

Kapazitäten, Kosten und Terminen

Motivation, Engagement und Zusammenarbeit aller

Beteiligten

Laufende Überwachung und (sofortige) Steuerung bei

Abweichungen

Ermittlung klarer, eindeutiger, erreichbarer und abgestimmter

Ziele (und Zwischenziele)


1.83 – 17.09.2012 Seite 23 von 228

PM Basis

Der englische Begriff: Triple Constraint

Das magische Dreieck des Projektmanagements

Die drei Aspekte Leistung (Ergebnis), Aufwand und Zeit werden permanent überprüft und abgeglichen; ein Projekt ist nur erfolgreich, wenn alle drei Aspekte ausreichend erfüllt werden!


Zeit(Termin)

Leistung,Ergebnis

(Qualität, Umfang)

Aufwand(Kosten)

• Funktion• Eigenschaften• Leistung• Qualität

• Termine• Ablauf• Ressourceneinsatz

• Aufwand/Kosten• Transparenz• Ressourceneinsatz


1.83 – 17.09.2012 Seite 24 von 228

PM Basis

Studien, die fehlgeschlagene Projekte ausgewertet haben, benennen folgende Ursachen für das Scheitern von Projekten: • Projektbeginn ohne klares Bedürfnis • Auswahl eines ungeeigneten Projektmanagers • Fehlende Unterstützung des Managements • Unzureichend definierte Aufgaben • Nicht effektive Anwendung des Projektmanagement-Prozesses • Widerwillen, das Projekt zu beenden • …

„Sage mir, wie das Projekt startet, und ich sage Dir wie es endet!“

„Ein Projekt ist erfolgreich, wenn alle berechtigten Interessen berücksichtigt werden und alle Beteiligten zufrieden sind!“

Projektmisserfolg (1/2): Ursachen



1.83 – 17.09.2012 Seite 25 von 228

PM Basis

/Schelle10/

Projektmisserfolg (2/2): Vorab-Prüfschema


NEIN

JA

JA JA

JAJA

JANEIN NEIN NEIN

NEIN NEINNEIN

JA

Ist die Projektidee mit dem

Unternehmensleitbild vereinbar?

Projektidee wird eliminiert!

Ausrichtung auf strategische Ziele des

Unternehmens

Projektidee wird dem Management

vorgelegt!

Ist das notwendige Know-how

vorhanden?

Sind ausreichende Kapazitäten vorhanden?

Wirtschaftlichkeits-steigerung?

Ist es zu einem annehmbaren Preis

erhältlich?

Sind sie zu einem annehmbaren Preis

erhältlich?


1.83 – 17.09.2012 Seite 26 von 228

PM Basis

• Jedes Projekt wird in eigenständige Zeitabschnitte (= Phasen) unterteilt (siehe nächste Folie)

• Die Bezeichnungsweisen für die Phasen sind je nach Projekt(gegenstand) unterschiedlich

• Während einer Phase müssen bestimmte Tätigkeiten durchgeführt werden, die (vorab) definiert sind; vorgegeben sind aber die Kick-Off-Sitzung zu Projektbeginn und die Kick-Out-Sitzung zum Abschluss des Projekts

• Jede Phase wird durch einen „Meilenstein“, d.h. durch ein überprüfbares Ergebnis (Liefergegenstand) mit Liefertermin abgeschlossen

• Zu einem Meilenstein gehören oftmals „Quality Gates“, die zur Überprüfung des Projektmanagementprozesses und des Projektgegenstands dienen

• Phasenmodelle sind vielfach bereits durch Firmen-, Branchen- oder sonstige Vorgaben vorbestimmt

• In der vereinfachten Darstellung finden sich nur die „Phasenelemente“

Projektphasen (1/5): Definition



1.83 – 17.09.2012 Seite 27 von 228

PM Basis

Das Zusammenwirken von Phasen und Gates wird als „Stage-Gate-Prinzip“ bezeichnet.

Projektphasen (2/5): Idealisierter Überblick


Tätigkeit 2.1 Tätigkeit 2.2 ...

Tätigkeit n-1.1Tätigkeit n-1.2...

Tätigkeit n.1 Tätigkeit n.2 ...

Tätigkeit 1.1 Tätigkeit 1.2 ...

Phase 1 Phase 2 Phase n-1 Phase n...

Liefergegen-stand 1

Liefergegen-stand 2

Liefergegen-stand n-1 Produkt

Kick-Off-Meeting

Kick-Out-Meeting

Meilensteine

Quality-Gates

Sitzung Treffen von Projektgremien

Liefergegen-stand 1

Liefergegenstand (i.A. Dokumente + Produkt)

Phase n Phase

Tätigkeit n.1 ...

Tätigkeiten während einer Phase


1.83 – 17.09.2012 Seite 28 von 228

PM Basis

• Jede Phase lässt sich wiederum in weitere (Unter-)Phasen unterteilen! • Jede Phase für sich verläuft nicht (unbedingt) statisch-linear, sondern kann auch

Iterationen aufweisen (siehe nächste Folie) • Es existieren etliche Phasenmodelle (abgeleitet aus den Vorgehensmodellen), die

eine vom Projektgegenstand abhängige Struktur aufweisen • Vorgehensmodell = Phasenmodell + Projektprozesse • Zwei Beispiele für Vorgehensmodelle: HOAI (Bauwesen), V-Modell-XT

(Softwareentwicklung)

Projektphasen (3/5): Minimalmodell


Vorprojekt / Start Planung Realisierung Abschluss

Start-phase

Arbeits-phase

Überprüfungs- & Steuerungs-

phase

Abschluss-phase


1.83 – 17.09.2012 Seite 29 von 228

PM Basis

Jede Phase lässt sich in die iterativen Abschnitte „Planung“, „Ausführung“ und „Überwachung & Steuerung“ unterteilen. Die Abschnitte „Initiierung“ und „Abschluss“ sind jedoch statisch.

Projektphasen (4/5): Weitere Unterteilung nach PMI


Initiierung

Ausführung

Abschluss

Planung

Überwachung & Steuerung


1.83 – 17.09.2012 Seite 30 von 228

PM Basis

Anmerkungen: • Die Phasen sind nicht immer klar voneinander zu trennen • Rücksprünge und Iterationen zwischen den Phasen treten in der Praxis

oftmals auf • Typische Werte: 4-7 Phasen (und Meilensteine) pro Projekt

HOAI (Honorarordnung für Architekten und Ingenieure):

SW-Entwicklung:

Projektphasen (5/5): Weitere Modelle


Aufgaben-analyse

Reali-sierung

Detail-Planung Installation Abnahme PflegeSystem-

planung

Grundlagen-ermittlung

Genehmigungs-planung

Entwurfs-Planung

Ausführungs-planung

Vorbereitung Vergabe

Mitwirkung Vergabe

Vor-planung

Bauüber- wachung

Objekt- betreuung


1.83 – 17.09.2012 Seite 31 von 228

PM Basis

• Ein Meilenstein fasst vordefinierte Ereignisse (Richtgrößen, Kontrollpunkte) zusammen

• Ein Meilenstein hat einen festen (Abschluss-)Termin • Der Meilensteinplan benennt alle Meilensteine und ist die Basis für die

Kontrolle des Projekts • Der Meilensteinplan verwendet nur eindeutig messbare Ereignisse

Der Meilensteinplan

Ist das Vorgehensmodell bereits fest vorgegeben, so müssen die Meilensteine nicht mehr definiert werden, sondern nur noch die Termine, wann sie erreicht werden!



1.83 – 17.09.2012 Seite 32 von 228

PM Basis Fragen zum Kapitel

1. Nennen Sie die wesentlichen Merkmale eines Projekts! 2. Was ist das magische Dreieck des Projektmanagements? 3. Was sind die Hauptgründe für das Scheitern von Projekten? 4. Wozu dienen Phasenpläne? Wer erstellt/entwickelt sie? 5. Nennen Sie die vier Phasen, die minimal immer durchlaufen

werden sollten!



1.83 – 17.09.2012 Seite 33 von 228

PM Basis

Kapitel 2: Projektziele

Kapi

tel 2

• Definition • Bedeutung • Einordnung der Zielentwicklung • Wohlgeformte Ziele • Checkliste (Projektziele) • Fragen zum Kapitel

Seite 33-39

Teil I

Zum Thema Ziele im Projekt und SMARTe Zielformulierung gibt es eine eigenständige Präsentation des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/_pdf/peco-pm-ziele.pdf frei verfügbar ist.

1. 2. 3. Projektziele I. 4. 5.

https://www.peterjohann-consulting.de/_pdf/peco-pm-ziele.pdf


1.83 – 17.09.2012 Seite 34 von 228

PM Basis

Nach DIN 69901-5:2009 /DIN09/ ist das Projektziel (engl. project scope/goal) die „Gesamtheit von Einzelzielen, die durch das Projekt erreicht werden.“ Ziele sind: • Geschäftsziele (Umsatz, Ergebnis, Marktanteile, Kundenzufriedenheit) • Prozessziele (Ergebnis, Aufwand, Zeit) • Teamziele (Kommunikation, Informationsfluss, Zusammenarbeit)

Ziele werden unterschieden nach: • Muss-Ziele • Soll-Ziele • Kann-Ziele „Ziele sollten nicht mit Wünschen verwechselt werden!“

Nach PMI /PBG08/ wird das Projektziel teilweise dem Projektumfang (engl. Project Scope) gleichgesetzt.

Projektziele (1/5): Definition



1.83 – 17.09.2012 Seite 35 von 228

PM Basis

Projektziele (2/5): Bedeutung

Nach Studien (z.B. der GPM) sind „unklare Anforderungen und Projektziele“ eine der häufigsten Ursachen für das Scheitern von Projekten. Klare Projektziele: • Bilden die Grundlage einer guten Planung • Dienen als Gradmesser für Erfolg und Misserfolg • Enthalten die Basis des Projektcontrollings Daher – die Projektziele (= angestrebte Projektergebnisse): • Müssen schriftlich festgelegt werden • Müssen messbar oder überprüfbar sein • Sollten positiv und wohlgeformt beschrieben werden (siehe spätere Folie) • Umfassen mindestens die Aspekte Ergebnis, Aufwand und Zeit (aus dem

magischen Dreieck) • Sollten unbedingt die Zufriedenheit der Stakeholder berücksichtigen • Werden vor dem „eigentlichen Projektstart“ ermittelt



1.83 – 17.09.2012 Seite 36 von 228

PM Basis

„Das Ziel ist das vorweggenommene Ergebnis!“

Projektziele (3/5): Einordnung der Zielentwicklung


Vision

Idee

Planung

Projekt-auftrag

ProjektVorprojektSammlung & Bewertung

Umfeld-/Situations-

analyse

Stakeholder-analyse Zielentwicklung Projektstart

Machbarkeits-und Wirtschaft-

lichkeits-betrachtung

Vorprojekt-antrag

Übertragung +Ergänzung

Projekt-ziele


1.83 – 17.09.2012 Seite 37 von 228

PM Basis

Wohlgeformte Ziele sind SMART: • Spezifisch konkret: Ist das Ziel genau formuliert? • Messbar: Kann ich objektiv erkennen, ob ich mein Ziel erreicht habe? • Aktiv beeinflussbar: Kann die Zielerreichung von den Projektmitgliedern

beeinflusst werden? (Anspruchsvoll, Attraktiv) • Realistisch: Ist das Ziel anspruchsvoll, aber auch erreichbar? • Terminiert: Sind die Termine klar festgelegt? Die englische Beschreibung lautet: Simple, Measurable, Achievable, Realistic, Timeable. Ziele sind lösungsfrei und sollten daher ergebnis- und nicht aufgabenbezogen formuliert werden! Ziele sollten (explizit) priorisiert werden. Durch die Messbarkeit der Ziele kann hier schon das Controlling ansetzen und die Erfolgsmessung starten.

Projektziele (4/5): Wohlgeformte Ziele



1.83 – 17.09.2012 Seite 38 von 228

PM Basis

Projektziele (5/5): Checkliste


Auch in PM-Checklisten

Frage Maßnahmen

Herrscht Einigkeit zwischen Projektmanager, Projektteam und dem Projektsponsor bei den Projektzielen?

Ist der Bezug zu den Unternehmenszielen erkennbar?

Sind die Projektziele realistisch und tatsächlich erreichbar?

Sind die Projektziele vollständig, eindeutig und widerspruchsfrei beschrieben?

Sind die Projektziele priorisiert?

Gibt es (grobe) Aufwandsabschätzungen für die einzelnen Projektziele?

Sind alle Projektziele schriftlich erfasst?

Ist jedes Projektziel messbar, mindestens aber überprüfbar formuliert?

Ja Nein Offen


1.83 – 17.09.2012 Seite 39 von 228


1. Skizzieren Sie den Zielentwicklungsprozess! 2. Wo halten Sie die Projektziele fest? 3. Was bedeutet SMARTe Zielformulierung? Warum ist das „M“

für den Projektmanager besonders wichtig?



1.83 – 17.09.2012 Seite 40 von 228

PM Basis

Kapitel 3: Stakeholdermanagement

Kapi

tel 3

• Definition • Beispiele • Stakeholdermanagement • Stakeholderliste • Stakeholder- oder Kraftfeldanalyse • Wirkungsanalyse • Klassifikation von Stakeholdern • Anmerkungen • Übung • Checkliste (Stakeholdermanagement) • Tipps zum Kapitel • Fragen zum Kapitel

Seite 40-53

Teil I

1. 2. 3. Stakeholdermanagement I. 4. 5.

Zum Stakeholdermanagement gibt es eine eigenständige Präsentation des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/_pdf/peco-pm-stakeholdermanagement.pdf frei verfügbar ist.

https://www.peterjohann-consulting.de/_pdf/peco-pm-stakeholdermanagement.pdf

https://www.peterjohann-consulting.de/_pdf/peco-pm-stakeholdermanagement.pdf


1.83 – 17.09.2012 Seite 41 von 228

PM Basis

Ein Stakeholder (selten: Projektbeteiligter oder Interessensgruppe) ist /PMag/ eine Person, Personengruppe oder eine Organisation, … • die aktiv am Projekt beteiligt ist oder durch den Projektverlauf oder das

Projektergebnis beeinflusst wird und • die gegebenenfalls den Projektverlauf oder das Projektergebnis

beeinflussen kann. In unserer Betrachtung können auch Dinge Stakeholder sein.

Generell wird zwischen internen (d.h. in dem Unternehmen arbeitenden) und externen (= außerhalb des Unternehmens agierenden) Stakeholdern unterschieden.

„To have stake in = Interesse haben an“

Definition


InterneStakeholder

Externe Stakeholder

Einstellung(Ziele,

Interessen)Betroffenheit Einfluss

(Macht)


1.83 – 17.09.2012 Seite 42 von 228

PM Basis

DIN 69901-5:2009 /DIN09/: Projektbeteiligte: (engl. stakeholder) Gesamtheit aller Projektteilnehmer, -betroffenen und -interessierten, deren Interessen durch den Verlauf oder das Ergebnis des Projekts direkt oder indirekt berührt sind.

Beispiele


Das Projekt

Kunden

Lieferanten

Öffentlich-keit

Geschäfts-führung

Mitarbeiter

Betriebsrat

Auftrag-geber(intern)Vertrieb

Konkur-renten

Behörden

Andere Abtei-lungen

BankenAktionäre

Projekt-manager

Betroffene Abteilungen


1.83 – 17.09.2012 Seite 43 von 228

PM Basis

Das Stakeholdermanagement beschäftigt sich mit … • der (Vorab-)Planung der Aktivitäten des Stakeholdermanagements (im

konkreten Projekt), • der Identifikation der Stakeholder/Projektbeteiligten, • der Analyse des Stakeholdereinflusses und der Stakeholderinteressen, • der Bestimmung der Anforderungen der Stakeholder, • dem erwarteten Verhalten der Stakeholder, • der Ableitung von Konsequenzen und Maßnahmen für das Projekt, • der aktiven Beeinflussung der Stakeholder (Projektmarketing) und • dem Steuern und Überwachen der Stakeholder.

Ein Regelkreis für das Stakeholdermanagement ist auf der nachfolgenden Folie dargestellt.

Stakeholdermanagement (1/2)



1.83 – 17.09.2012 Seite 44 von 228

PM Basis

Die einzelnen Dokumente werden auf den nächsten Folien erklärt.

Stakeholdermanagement (2/2)


1. Stakeholder- identifikation

2. Stakeholder- analyse

3. Stakeholder-behandlung

4. Stakeholder-steuerung

a) Projektmarketing b) Mängel-/Wunschliste

a) Einflussb) Einstellung

0. Stakeholder- management- planung

Stakeholder-liste

Kraftfeld-analyse

Wirkungs-analyseWunschliste

a) Benennungb) Erwartung


1.83 – 17.09.2012 Seite 45 von 228

PM Basis

Zur systematischen Stakeholderidentifikation (und Vorab-Analyse) wird die Stakeholderliste benutzt. Sie kann folgenden Aufbau haben:

Aus der Stakeholderliste kann recht einfach eine grafische Repräsentation abgeleitet werden: Diese wird als Stakeholder- oder Kraftfeldanalyse bezeichnet (siehe nächste Folie).

Stakeholderliste


Wer nimmt Einfluss auf das Projekt? Wer ist von ihm betroffen?

Welche Erwartungen bestehen an das

Projekt?

Wie ist die Einstellung zum Projekt?

Wie stark ist der Einfluss der Person/Gruppe?

positiv +, neutral o, negativ - niedrig, mittel, hoch

/SchuWi02/


1.83 – 17.09.2012 Seite 46 von 228

PM Basis

für das Projekt

gegen das Projekt

starker Einfluss

schwacher Einfluss

Vorstand Kunden

Vertrieb

Mitarbeiter

BehördenAktionäre

Banken Betriebsrat

Einstellung

Einfluss

UnterstützungKonflikte

/SchuWi02/

DIN 69901-5:2009 /DIN09/: Stakeholderanalyse: (engl. stakeholder analysis) Analyse der Projektbeteiligten hinsichtlich deren Einfluss auf das Projekt und deren Einstellung (positiv oder negativ) zum Projekt.

Stakeholder- oder Kraftfeldanalyse



1.83 – 17.09.2012 Seite 47 von 228

PM Basis

Die Wirkungsanalyse ist besonders für die internen Stakeholder interessant, um mögliche Widerstände und Motivationsfaktoren zu erkennen.

/SchuWi02/

Wirkungsanalyse


Wie wirkt sich das Projekt auf die folgenden Faktoren aus?

Individuelle Wirkungsanalyse

Stärke der AuswirkungArt der Auswirkung

Stakeholder (Rolle oder Name)

Sicherheit des Arbeitsplatzes

Inhalt der Aufgaben

Kompetenzen

Verantwortung

Arbeitsbelastung

Gehalt

Aufstiegsmöglichkeiten

Soziale Kontakte

negativ -, neutral o, positiv + gering -, mittel o, stark +


1.83 – 17.09.2012 Seite 48 von 228

PM Basis

Die GPM /GPM12/ unterscheidet zwischen sachlichen und sozialen Stakeholdern und ordnet diese den internen und externen Stakeholdern zu.

Die Grenze des eigenen Unternehmens bildet hier die Grenze zwischen „Intern“ und „Extern“.

/GPM12/

Klassifikation von Stakeholdern


• Betriebsvereinbarung• PM-Handbuch• Richtlinien• Umsatzentwicklung

Intern Extern

Sozial

Sachlich

• Betriebsrat• Beauftragter• Vorstand, Abteilungsleiter• Mitarbeiter (außerhalb des

Projekts)

• Gesetze• Normen und Standards• RFCs (Request for

Comments)• Marktentwicklung

• Auftraggeber (AG)• Mitarbeiter der AG-

Organisation• Lieferanten• Kunden


1.83 – 17.09.2012 Seite 49 von 228

PM Basis

• Zum Stakeholdermanagement gibt es eine Reihe von Untersuchungen und Vorgehensweisen. Ebenso ist eine große Anzahl von Büchern erhältlich

• Verwandte Gebiete zum Stakeholdermanagement: Risikomanagement, Kommunikationsmanagement

• Gleichzeitig ist das Stakeholdermanagement eines der Kerngebiete des Requirements Engineering

Anmerkungen


Zum Thema Requirements gibt es eine eigenständige Präsentation des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/_pdf/peco-re-einfuehrung.pdf frei verfügbar ist.

https://www.peterjohann-consulting.de/_pdf/peco-re-einfuehrung.pdf

https://www.peterjohann-consulting.de/_pdf/peco-re-einfuehrung.pdf


1.83 – 17.09.2012 Seite 50 von 228

PM Basis

Identifizieren Sie die Stakeholder in Ihrem Projekt (mit der Stakeholderliste) und erstellen Sie eine Kraftfeldanalyse.

Dauer: 20 Min.

Keine Muster-lösung!

Übung



1.83 – 17.09.2012 Seite 51 von 228

PM Basis

Stakeholdermanagement: Checkliste: „Sind die Stakeholder passend erfasst?“



Frage

Wurden alle internen und externen Stakeholder erfasst?

Konnten die Erwartungen der Stakeholder an das Projekt ermittelt werden?

Konnten die Einstellungen der Stakeholder zum Projekt ermittelt werden?

Wurden Maßnahmen zur aktiven Beeinflussung der besonders kritischen Stakeholder festgelegt?

Wurden Termine zur Überprüfung des Stakeholderverhaltens und -einflusses festgelegt?

Wurden die Ergebnisse der Stakeholderanalyse in die Kommunikationsmatrix und das Risikoregister eingearbeitet?

Bei Bedarf: Wurden Wirkungsanalysen und Mängel-/Wunschlisten erstellt?

MaßnahmenJa Nein Offen


1.83 – 17.09.2012 Seite 52 von 228

PM Basis

1. Führen Sie unbedingt vor Projektstart eine Stakeholderanalyse durch

2. Beachten Sie auch technische (z.B. Schnittstellen) oder gesetzliche Stakeholder

3. Planen Sie Zeiten für das Stakeholdermanagement ein!

Tipps zum Kapitel



1.83 – 17.09.2012 Seite 53 von 228

PM Basis

1. Erklären Sie die Aufgaben des Stakeholdermanagements! 2. Warum ist es (für Sie als Projektmanager) besonders wichtig,

die Stakeholder vor Projektbeginn zu identifizieren? 3. Wer führt die Stakeholderanalyse durch? Können Sie (als

Projektmanager) Aufgaben des Stakeholdermanagements delegieren?

4. Wie und wo notieren Sie die Stakeholderliste (und die daraus abgeleitete Kraftfeldanalyse)?

5. Warum ist die Wirkungsanalyse bei Organisationsprojekten besonders wichtig?

6. Wie viel Prozent Ihrer Zeit (als Projektmanager) benötigen Sie für das Stakeholdermanagement? Wie sieht dies bei kleinen/mittleren/großen Projekten aus?

7. Welchen Zusammenhang gibt es zwischen der Stakeholderanalyse und dem Risikomanagement?

Fragen zum Kapitel



1.83 – 17.09.2012 Seite 54 von 228

PM Basis

Kapitel 4: Projektorganisation und Rollen im Projekt

Kapi

tel 4

• Projektorganisation: Grundsätzliches • Projektorganisation (Allgemein, Reine Linienorganisation,

Stab-Linienorganisation, Reine Projektorganisation, Matrixorganisation, Ausprägungen der Matrixorganisation, Vergleich der Organisationsformen, Anmerkungen)

• Projektgremien (Allgemein, Minimaler Aufbau, Interner Aufbau des Projektteams, Aufbau für große Projekte)

• Weitere Rollen im Projekt • Der Projektmanager (Aufgaben, Kernkompetenzen,

Besonderheiten) • Tipps zum Kapitel • Fragen zum Kapitel

Seite 54-74

Teil I

1. 2. 3. Projektorganisation und Rollen im Projekt I. 4. 5.


1.83 – 17.09.2012 Seite 55 von 228

PM Basis

Nach DIN 69901-5:2009 /DIN09/ ist die Projektorganisation (engl. project organization): „Aufbau- und Ablauforganisation zur Abwicklung eines bestimmten Projekts“, wobei angemerkt wird, dass „die Projektorganisation aus Bestandteilen der vorhandenen Betriebsorganisation bestehen kann“, die „dann lediglich durch projektspezifische Regelungen ergänzt wird“. Die internationale Norm ISO 10006 (in /DIN09/ enthalten) unterscheidet etwas feiner zwischen „Trägerorganisation“ und „Projektorganisation“: • Die Trägerorganisation ist diejenige Organisation, welche entscheidet, das Projekt

durchzuführen. Sie kann als Einzel-Organisation, Gemeinschaftsunternehmen (engl. joint venture), Konsortium usw. eingerichtet sein. Die Trägerorganisation weist das Projekt einer Projektorganisation zu. Die Trägerorganisation kann eine Vielzahl von Projekten durchführen, von denen jedes einer anderen Projektorganisation zugewiesen werden kann

• Die Projektorganisation führt das Projekt durch. Die Projektorganisation kann ein Teil der Trägerorganisation sein

Die Projektorganisation: Grundsätzliches



1.83 – 17.09.2012 Seite 56 von 228

PM Basis

Die Aufbauorganisation eines Unternehmens bestimmt maßgeblich, wie erfolg-reich ein Projekt sein kann. Nur wenn die Organisation das Projekt stützt, kann das Projekt erfolgreich sein. Folgende Organisationsformen kommen in Unternehmen in der Praxis vor (siehe nächste Folien): • Reine Linienorganisation (auch Einflußorganisation): Hier werden aus der Linie

(Abteilung, Fachbereich) heraus Projekte mit Linienmitarbeitern bearbeitet; der Projektmanager kommt aus der Linie und bleibt der Linie zugeordnet

• Stab-Linienorganisation: Neben der Linie existieren Stabsstellen, die Projekte zu verantworten haben; diese Stäbe sind direkt dem obersten Linienverantwortlichen zugeordnet

• Reine Projektorganisation: Die Linie hat für die Projektarbeit keine Relevanz; alle Projektteammitglieder werden (temporär) dem Projekt zugeordnet und haben keine Aufgaben in der Linie

• Matrixorganisation: Neben der Linienorganisation gibt es eine Projektorganisation. Die Mitarbeiter werden dem Projekt und der Linie zugeordnet und sind in beiden Bereichen tätig

Die Projektorganisation (1/8): Allgemein



1.83 – 17.09.2012 Seite 57 von 228

PM Basis

Der Projektmanager kommt aus dem Fachbereich und ist dort auch jemandem unterstellt.

Die Projektorganisation (2/8): Reine Linienorganisation


Fach-bereich 1

MA1

AL

MA2 MA3 MA1

AL

MA2 MA3 MA1

AL

MA2 MA3

Fach-bereich 2

Unternehmens-leitung

Projekt


1.83 – 17.09.2012 Seite 58 von 228

PM Basis

Der Projektmanager wird von der Unternehmens-leitung bestimmt und ist dieser direkt unterstellt.

Die Projektorganisation (3/8): Stab-Linienorganisation


Fach-bereich 1

MA1

AL

MA2 MA3 MA1

AL

MA2 MA3 MA1

AL

MA2

Fach-bereich 2


Projekt

Projektstab

MA3


1.83 – 17.09.2012 Seite 59 von 228

PM Basis

PTM: Projektteam- mitarbeiter

Der Projektmanager agiert eigenständig und unabhängig von der Linie und berichtet an die Unternehmensleitung. Die Projektteammitarbeiter werden aus der Linie herausgelöst.

Die Projektorganisation (4/8): Reine Projektorganisation


Fach-bereich

MA1

AL

MA2 MA3 MA1

AL

MA2 MA3 PTM1 PTM2


Projekt

PTM3X X X


1.83 – 17.09.2012 Seite 60 von 228

PM Basis

Der Projektmanager agiert eigenständig und unabhängig von der Linie und berichtet an die Unternehmensleitung.

Die Projektorganisation (5/8): Matrixorganisation


Fachbereich 1 Fachbereich 2 Fachbereich 3

Projekt-manager B

Proj

ektv

eran

twor

tung

MA1 MA2 MA3

PTM1 PTM2

PTM3

MA1 MA2 MA3

PTM1 PTM2

MA1 MA2 MA3

Projekt-manager A



1.83 – 17.09.2012 Seite 61 von 228

PM Basis

Die Matrixorganisation ist eine Mischform der reinen Linien- und der reinen Projektorganisation. In der Praxis hat sie die größte Bedeutung, da sie zum einen vorhandene Unternehmensstrukturen nutzt, zum anderen aber Projekte(rfolge) möglich macht. Bei der Matrixorganisation werden drei Ausprägungen unterschieden: • Schwache Matrix (engl. weak matrix): Die Linie hat Vorrang. Die Projektmitarbeiter

sind disziplinarisch weiterhin ihrem Linienvorgesetzten unterstellt. Der Projektmanager hat nur geringe Befugnisse

• Ausgewogene Matrix (engl. balanced matrix): Linientätigkeit und Projektmitarbeit stehen gemeinsam im Fokus. Die Mitarbeiter sind sowohl dem Linienvorgesetzten wie auch dem Projektmanager unterstellt

• Starke Matrix (engl. strong matrix): Das Projekt hat Vorrang. Die Projektmitarbeiter sind disziplinarisch weiterhin dem Projektmanager unterstellt, der sich jedoch mit dem Linienvorgesetzten abspricht. Der Projektmanager hat weitreichende Befugnisse, insbesondere im budgetären Bereich

Die Projektorganisation (6/8): Ausprägungen der Matrixorganisation



1.83 – 17.09.2012 Seite 62 von 228

PM Basis

Die Projektorganisation (7/8): Vergleich der Organisationen


sehr groß

Linienorganisation ReineProjektorganisation Matrixorganisation

gering großBedeutung für das Unternehmen

Umfang des Projekts

Unsicherheit der Zielerreichung

Technologie

Projektdauer

Komplexitätsgrad

Bedürfnis nach zentraler Steuerung

Mitarbeitereinsatz

Anforderung an die PjM-Persönlichkeit

sehr großgering groß

hochgering mittel

Standard neu kompliziert

hohe Anforderung an die Persönlichkeit

hochqualifizierter PjM mit guten Methoden- und Fachkenntnissen

hochqualifizierter PjMmit guten Methoden-kenntnissen

kurz lang mittel bis lang

gering

gering

nebenamtlich hauptamtlich Teilzeit

mittel

großsehr groß

hoch


1.83 – 17.09.2012 Seite 63 von 228

PM Basis

Welche Projektorganisationsform nun „optimal“ ist, hängt vom Umfeld und vom Projekt selber ab. Bei kleineren Projekten ist es oftmals sinnvoll, die Linienstruktur zu nutzen, während große Projekte mit vielen neuen Elementen (F&E-Projekte, Pionierprojekte) bevorzugt die Projektorganisation benutzen. In der Praxis gibt es auch Mischformen der Organisationsformen. Zudem können je nach Phase in einem Projekt die Organisationsformen wechseln. Dies ist sinnvoll, wenn in einer bestimmten Phase (zumeist die Realisierungs- oder Umsetzungsphase) besonders intensiv nach Projekt-Prinzipien gearbeitet werden muss. Die wesentlichen Unterschiede der Organisationsformen sind in folgenden Punkten zu sehen: • Befugnisse des Projektmanagers: Ist der Projektmanager stark in der Linie

verankert, so werden die wesentlichen Projektentscheidungen nicht vom ihm getroffen. Er wird dann zum reinen „Projektkoordinator“

• Disziplinarische Einbindung der Mitarbeiter: Wenn die Mitarbeiter im starken Maße der Linie zugeordnet sind, so kann (je)der Linienvorgesetzte Einfluss auf das Projekt nehmen. Der Projekterfolg wird hierdurch erschwert

Die Projektorganisation (8/8): Anmerkungen



1.83 – 17.09.2012 Seite 64 von 228

PM Basis

Ein Projekt muss zumindest folgende Beteiligte („Rollen“) aufweisen: • Einen Auftraggeber (intern oder extern; externe Auftraggeber werden auch als

Kunden bezeichnet), der Interesse an der Umsetzung des Projekts hat und auch die Mittel zur Umsetzung bereitstellen kann

• Einen Projektsponsor (intern), der ebenfalls Interesse an der Umsetzung des Projekts und die Befugnis hat, für das Projekt kaufmännische Vorgaben zu machen und durchzusetzen. Er ist „interner Kunde“

• Ein verantwortliches Managementgremium (Lenkungsausschuss, engl. steering committee), welches das Projekt beauftragt, das Budget bewilligt, den Projektmanager benennt und während der Projektlaufzeit das Projekt grob steuert. Der Projektsponsor ist immer Mitglied des Lenkungsausschusses

• Einen Projektmanager, der für die Erfüllung des Projektauftrags und die Erreichung des Projektziels verantwortlich ist. Er ist „Unternehmer auf Zeit im Unternehmen“

• Ein Projektteam (aus Projektteammitarbeitern), welches die Aufgaben umsetzen muss. Das Projektteam besteht aus ständigen und temporären Mitgliedern

Projektgremien (1/4): Allgemein



1.83 – 17.09.2012 Seite 65 von 228

PM Basis

Projektgremien (2/4): Minimaler Aufbau

Hier ist der Kunde intern (und damit Projektsponsor), wird nicht extra ausgewiesen und ist Mitglied des Lenkungsausschusses.


Projektteam

Lenkungsausschuss(Steering Committee)

Projektmanager


1.83 – 17.09.2012 Seite 66 von 228

PM Basis

Projektgremien (3/4): Interner Aufbau des Projektteams

TPM: Teilprojektmanager PTM: Projektteammitarbeiter MA: Mitarbeiter (generell)


Projektteam

Kernteam

Projektmanager

MA1

MA2

MA3

PTM1 PTM2 PTM3PTM6

PTM5

TPM

PTM4



1.83 – 17.09.2012 Seite 67 von 228

PM Basis

Projektgremien (4/4): Aufbau für große Projekte


Projektteam

Kernteam

Kunde (externer Auftraggeber)


Projektmanager

Projektcontrolling(extern)

PMO – Project Management

Office (extern)Qualitätssicherung

(extern)

Fachausschuss(Review Board)

Projektbüro

Projektsponsor(interner Auftraggeber)


1.83 – 17.09.2012 Seite 68 von 228

PM Basis

• Die Projektteammitglieder (PTM): Stehen dem Projekt zur Verfügung und sind stärker dem Projekt als einer Linienorganisation zugeordnet. Das Projektkernteam umfasst nur die Projektteammitglieder

• Die Fachabteilungsmitarbeiter (MA): Werden temporär für das Projekt aus den Fachabteilungen dem Projektteam zugeteilt, sind aber ansonsten in der Linienorganisation eingeordnet

• Ggf. Teilprojektmanager (TPM), falls das Projekt aufgrund der Größe oder Komplexität in einzelverantwortbare Bereiche (Teilprojekte – TPRJ) untergliedert wird

• Das Project Management Office (PMO): Stabsgremium, welches beim Aufsetzen von Projekten hilft. Definiert zu Beginn, welches Vorgehens-modell verwendet wird und welche Dokumente erstellt werden müssen. Ist dem Management unterstellt

• Der Fachausschuss (oder Review Board): Dies sind Mitarbeiter aus betroffenen oder beteiligten Fachabteilungen, die bei fachlichen Fragen Entscheidungsbefugnis haben

Weitere Rollen im Projekt (1/2)



1.83 – 17.09.2012 Seite 69 von 228

PM Basis

• Die Qualitätssicherung: Gremium zur Überwachung der Qualität (sowohl Inhalts- wie Prozess-Qualität) im Projekt. Ist im Allgemeinen dem Management und nicht dem Projektmanager unterstellt

• Das Projektcontrolling: Gremium zur Unterstützung der Überwachung (und Steuerung) des Projekts; liefert dem Projektmanager die zur Entscheidung notwendigen Auswertungen. Ist im Allgemeinen dem Management und nicht dem Projektmanager unterstellt

• Das Projektbüro (Project Office, PO): Zentrale Anlaufstelle für alle administrativen Tätigkeiten im Projekt. Hier werden die Projektdokumente gepflegt und die Projektberichte zusammengestellt

Weitere mögliche Rollen (nicht in den Grafiken dargestellt): • Das Change Control Board (CCB): Gremium, welches über Änderungs-

anforderungen entscheidet • Der Projekt Mentor (oder Projekt Pate): Mitglied des Managements, welches dem

Projekt(manager) beratend zur Seite steht (Senioritätsprinzip), viel Projekterfahrung hat, aber nicht direkt in das Projekt involviert ist

Weitere Rollen im Projekt (2/2)



1.83 – 17.09.2012 Seite 70 von 228

PM Basis

Der Projektmanager (1/3): Aufgaben

Das PMI /PBG08-d/ definiert den Projektmanager folgendermaßen: „Die von der Trägerorganisation für die Erreichung der Projektziele bestimmte Person.“ Der Projektmanager ist verantwortlich für alle Aspekte des Projekts, darunter unter anderem /PBG08-d/: • Aufstellung des Projektmanagementplans und allen zugehörigen

Komponentenplänen • Einhaltung der Projekttermine und des Projektbudgets • Erkennen, Überwachen und Bewältigung von Risiken • Genaue und unverzügliche Berichterstattung über die Projektmetriken

Achtung: Der Begriff Projektleiter (eher technisch) und Projektmanager (eher kauf-männisch) wird in Deutschland gleichermaßen verwendet. Wir benutzen hier nur Projektmanager (abgekürzt PjM)!



1.83 – 17.09.2012 Seite 71 von 228

PM Basis

fachlich

sozial methodisch

Kompetenzen

erlernbar

zum Teil erlernbar

zum Teil erlernbar

Der PjM muss neben den „handwerklichen Fähigkeiten“ (fachlich-technisch, methodisch) auch „weiche Fähigkeiten“ (soziale Kompetenzen) mitbringen.

Der Projektmanager (2/3): Kernkompetenzen



1.83 – 17.09.2012 Seite 72 von 228

PM Basis

• Oftmals hat der Projektmanager keine zugewiesenen Kompetenzen, sondern ist in einer Linienstruktur eingegliedert

• Nur wenn der Projektmanager mit ausreichenden Kompetenzen ausgestattet ist, kann er das Projekt aktiv gestalten

• An ihm „hängt“ das ganze Projekt • Er muss unterschiedliche Fähigkeiten mitbringen und vereinen • Unbedingt notwendig sind kommunikative Fähigkeiten • Er benötigt Produkt-, Unternehmens- und Branchenkompetenz • Er ist der zentrale Anlaufpunkt für alle Beteiligten bei allen

organisatorischen, nicht aber notwendigerweise bei fachlichen Fragen

Der Projektmanager (3/3): Besonderheiten



1.83 – 17.09.2012 Seite 73 von 228

PM Basis Tipps zum Kapitel

1. Machen Sie vorab klar, wer die Rollen in Ihrem Projekt besetzt

2. Achten Sie darauf, dass die Gremien eine „passende Größe“ haben

3. Wenn Ihnen Qualifikationen zur Ausübung Ihrer PjM-Tätigkeit fehlen, so kommunizieren Sie diese gegenüber dem Management und lassen sich coachen oder nachschulen



1.83 – 17.09.2012 Seite 74 von 228


1. Wie heißen die drei Projektorganisationsformen? 2. Welche Projektorganisationsformen ist die beste (für Ihr

Projekt)? 3. Warum gibt es genau einen Projektsponsor? 4. Was sind die Projektgremien in einem kleinen Projekt? 5. Was sind die (notwendigen) Kernkompetenzen des

Projektmanagers?



1.83 – 17.09.2012 Seite 75 von 228

PM Basis

Kapitel 5: Projektstart und Projektdokumente

Kapi

tel 5

• Der Projektstart (Grundsätzliches, Tipps) • Der Projektauftrag (Grundsätzliches, Beispiel) • Das Kick-Off-Meeting (Grundsätzliches, Ablauf, Ziele) • Projektdokumente (Grundsätzliches, Arten, Übersicht,

Minimalzusammenstellung) • Das Projekthandbuch • Fragen zum Kapitel

Seite 75-88

Teil I

1. 2. 3. Projektstart und Projektdokumente I. 4. 5.


1.83 – 17.09.2012 Seite 76 von 228

PM Basis

• Das (eigentliche) Projekt beginnt nach dem Zielfindungsprozess und der Beauftragung durch den Kunden oder Auftraggeber; hierzu wird der Projektauftrag ausgefüllt und von den Beteiligten unterschrieben

• Der Kunde (sowie der Projektsponsor) muss bekannt sein und seine Zielvorstellungen sind geklärt und schriftlich fixiert

• Das Management konstituiert einen Lenkungsausschuss (engl. steering committee), der über das weitere Projektvorgehen zu entscheiden hat

• Der Lenkungsausschuss bestimmt den Projektmanager • Die Projektorganisation wird durch den Lenkungsausschuss in Zusammen-

arbeit mit dem Projektmanager festgelegt und die Teammitglieder bestimmt • Ein erstes Treffen für die Teammitglieder, das sogenannte „Kick-Off-

Meeting“, wird angesetzt und zeitnah durchgeführt • … die (Detail-)Planungen und damit das Projekt (im engeren Sinn)

beginnen …

Der Projektstart (1/2): Grundsätzliches



1.83 – 17.09.2012 Seite 77 von 228

PM Basis

Der Projektstart (2/2): Tipps

1. Der Projektmanager und die Projektbeteiligten müssen rechtzeitig benannt werden

2. Die Projektziele müssen klar, realistisch und messbar sein 3. Eine Stakeholderanalyse muss vorab durchgeführt werden 4. Die Chancen und Risiken müssen untersucht und

kommuniziert worden sein 5. Die Kommunikation zwischen den Beteiligten muss klar

geregelt werden 6. Die Verantwortung und die Kompetenzen müssen festgelegt

sein 7. Die Aufwände müssen (realistisch) geschätzt worden sein



1.83 – 17.09.2012 Seite 78 von 228

PM Basis

• Der Projektauftrag (engl. Project Charter) ist ein internes Dokument zwischen dem Projektsponsor, dem Lenkungsausschuss und dem Projektmanager, der hierdurch offiziell zum Projektmanager benannt wird

• Im Projektauftrag werden die Ziele und Randbedingungen genannt; ein (vollständiger) Projektplan mit Zeit- und Kostenplänen ist nicht enthalten

• Der Projektauftrag wird vor dem Projektstart vollständig ausgefüllt und von den Beteiligten unterschrieben

Der Projektauftrag (1/2): Grundsätzliches

• Synonyme: Projektvereinbarung, Projektvertrag, Projektcharta

• Nicht verwechseln mit: Projektantrag, Leistungsbeschreibung

• Nach der Unterzeichnung des Projektauftrags sollte unmittelbar die erste Kick-Off-Sitzung durchgeführt werden (übernächste Folie)


Projektauftrag

Randbedingungen(Constraints)

Ziele(Objectives)

Annahmen(Assumptions)

Liefergegenstände(Deliverables)


1.83 – 17.09.2012 Seite 79 von 228

PM Basis

Geschäftlicher Nutzen

Beteiligte / Stakeholder

Unterschriften Projektsponsor, Lenkungsausschuss

Gesamtdauer/-aufwand Meilensteine Gesamtkosten

Annahmen und Randbedingungen

Notwendige Mitarbeiter, zugewiesene Mitarbeiter, Projektorganisation

Unterschrift Projektmanager

Zu erbringende Ergebnisse

Projektmanager/-verantwortlicher

Projekttitel und Beschreibung Projekt-Id

Projektsponsor / Auftraggeber

Datum Version

Umsetzungsstart

Sonstiges

Der Projektauftrag (2/2): Beispiel

In der Regel ist der Projekt-auftrag sehr viel umfang-reicher, hier ist nur eine Minimalvariante dargestellt. Der Projektauftrag wird vom Projektsponsor (oder Len-kungsausschussvorsitzenden) und vom Projektmanager unterschrieben (grüne Pfeile). Was noch hinzugefügt werden könnte: • Risikobetrachtung • Lenkungsausschuss • Berichtsplan • …



1.83 – 17.09.2012 Seite 80 von 228

PM Basis

• Das Kick-Off-Meeting wird zu Beginn des Projekts durchgeführt und symbolisiert den eigentlichen Projektstart („Spatenstich“)

• Vorab sind die Projektziele definiert und der Projektauftrag erteilt worden; damit sind auch der Projektmanager und das Projektkernteam benannt

• Zu diesem Zeitpunkt sind ebenfalls grob bekannt: Das Phasenmodell mit den Meilensteinen, der Start- und Endtermin und der Umfangs- und Kostenrahmen

• Teilnehmer sind alle Projektteammitglieder (des Kernteams) und gegebenenfalls ausgewählte Lenkungsausschussmitglieder

• (Grob-)Ziel des Kick-Off-Meetings (intern): Entwicklung eines gemeinsamen Verständnisses des Projekts; damit kann direkt begonnen werden

• Dauer: Je nach Größe des Projekts und Projektkultur zwei Stunden bis zwei Tage

Das Kick-Off-Meeting (1/3): Grundsätzliches



1.83 – 17.09.2012 Seite 81 von 228

PM Basis

Ein Kick-Off-Meeting sollte in etwa folgenden Ablauf/folgende Agenda haben: • Vorstellen des Projekts (durch den Projektmanager oder Projektsponsor) • Klären der Bedeutung des Projekts und der Motivation für das Projekt • Motivation der Teilnehmer/Teammitglieder • Vorstellen der einzelnen Teammitglieder (und deren Aufgaben/Rollen im

Projekt) • Verteilung erster Unterlagen (z.B. Projekthandbuch) • Klärung/Erarbeitung der Rahmenbedingungen im Projekt – Wer macht

was? • Vorstellung der Kommunikationsregeln und des Berichtswesens • Entwickeln der ersten Pläne, insbesondere des Projektstrukturplans • Einstieg in die unmittelbare Umsetzung: „Die nächsten Schritte“

Das Kick-Off-Meeting (2/3): Ablauf



1.83 – 17.09.2012 Seite 82 von 228

PM Basis

Detailziele des Kick-Off-Meetings für das Projektteam sind: • Jeder Teilnehmer muss das Projekt als Ganzes und sein Teilprojekt

einordnen können • Die zeitlichen Vorgaben (inkl. der Meilensteine) sollten explizit

angesprochen werden • Die Organisationsstrukturen müssen klar sein • Jeder muss den Projektmanagementplan mit seinen Einzeldokumenten

verstehen • Wesentliche Projektmerkmale müssen geklärt sein (Bedeutung für das

Unternehmen, Vertraulichkeit) • Die maßgeblichen Regeln für die Projektarbeit werden vorgestellt

(Abstimmung, Verantwortlichkeiten, Arbeitsablauf) • Das Kommunikations- und Informationsmanagement wird durchgesprochen

(Kommunikationsmatrix, Besprechungs- und Berichtszyklen)

Das Kick-Off-Meeting (3/3): Ziele



1.83 – 17.09.2012 Seite 83 von 228

PM Basis

Nach der DIN 69901-5:2009 /DIN09/ ist die Projektdokumentation (engl. project documentation) die „Gesamtheit aller relevanten Dokumente, die in oder aus einem Projekt entstehen, Verwendung und Anwendung finden oder anderen Bezug zum Projekt haben.“ Wie viele (verschiedene) Dokumente sind für ein Projekt notwendig? Hier gibt es keine eindeutige Aussage. PMI /PBG08/ benennt etwa 40 verschiedene Dokumente, PRINCE2 /OGC09/ kennt genau 26 (und liefert dafür Vorlagen mit), GPM /GPM12/ und DIN /DIN09/ bewegen sich in einer ähnlichen Größenordnung wie das PMI.

Projektdokumente (1/4): Grundsätzliches

Projektdokumente sind entweder: • Statisch (werden einmal ausgefüllt und gelten dann als fixiert); Beispiele: Alle

Berichte, Protokolle, alle vertragsrelevanten Dokumente, Basispläne • Lebend (werden aufgesetzt und dann fortlaufend erweitert bzw. geändert);

Beispiele: Fast alle Pläne, Änderungslisten, Liste-offener-Punkte



1.83 – 17.09.2012 Seite 84 von 228

PM Basis

Generell gibt es mehrere Arten von Projektdokumenten: • Organisationsdokumente („wer hat welche Aufgaben oder Rollen im

Projekt?“); Beispiele: Projekthandbuch, Projektorganisationsstruktur, ... • Auftrags- und Inhaltsdokumente („was muss gemacht werden/was macht

das Produkt?“); Beispiele: Projektauftrag, Lastenheft, Pflichtenheft, ... • Planungsdokumente („wann und durch wen soll etwas gemacht werden?“);

Beispiele: Projektmanagementplan, Projektstrukturplan, Kostenplan, ... • Steuerungsdokumente und Berichte („wo steht das Projekt?“); Beispiele:

Projektstatusbericht, Qualitätsbericht, Risikobericht, Besprechungs-bericht, Liste-offener-Punkte, ...

• Abschlussdokumente („wie ist das Projekt beendet worden?“); Beispiele: Projektabschlussbericht, Abnahmeprotokoll, ...

• Die Arten sind nicht strikt voneinander zu trennen – gerade der sogenannte Projektmanagementplan umfasst viele unterschiedliche Dokumente

Projektdokumente (2/4): Arten



1.83 – 17.09.2012 Seite 85 von 228

PM Basis

Projektdokumente (3/4): Übersicht (unvollständig)


• Projekthandbuch• Projektorganisationsstruktur• Organigramm• Stakeholderliste

Organisationsdokumente

• Ausschreibung• Anfrage• Lastenheft• Projektantrag• Angebot• Projektauftrag (Prj-Charter)• Pflichtenheft• Änderungsantrag• Machbarkeits- und

Wirtschaftlichkeitsanalyse

Auftrags- und Inhaltsdokumente

• Projektmanagementplan• Projektstrukturplan• Arbeitspaketbeschreibungen• Terminplan• Kostenplan• Ressourcenbedarfsplan

Planungsdokumente

• Projektstatusbericht• Qualitätsbericht• Risikobericht• Besprechungsbericht• To-Do-Liste• LOP (Liste-offener-Punkte)

Steuerungsdokumente und Berichte

• Projektabschlussbericht• Abnahmeprotokoll• Übergabeprotokoll• Übernahmeprotokoll• Nachkalkulation

Abschlussdokumente

Planung

Überwachung & Steuerung

AbschlussAusführung

Initialisierung, Definition


1.83 – 17.09.2012 Seite 86 von 228

PM Basis

Um ein Projekt durchzuführen, sollten zumindest folgende (fünf) Projektdokumente erstellt und gepflegt werden: • Der Projektauftrag/Project Charter: Benennt den Projektmanager und die

Rahmenbedingungen für das Projekt (bereits erklärt/beschrieben) • Das Projekthandbuch: „Enthält alle notwendigen“ organisatorischen

Vorgaben und Rahmenbedingungen des Projekts (Erläuterung nächste Seite)

• Der Projektmanagementplan: Hierunter werden der Projektstrukturplan, der Projektterminplan, der Kostenplan und weitere Dokumente verstanden (Erläuterung in späterem Kapitel)

• Die Projektstatusberichte: Zu den Berichtszeitpunkten sollten einige Berichte erstellt werden, die es erlauben, das Projekt zielgerichtet zu steuern (Erläuterung in späterem Kapitel)

• Der Projektabschlussbericht: Mit Abschluss des Projekts erfolgt hierüber die formale Freigabe und die Wissenssicherung (Erläuterung in späterem Kapitel)

Projektdokumente (4/4): Minimalzusammenstellung



1.83 – 17.09.2012 Seite 87 von 228

PM Basis

• Ist nach DIN 69901-5:2009 /DIN09/ die "Zusammenstellung von Informationen, Standards und Regelungen, die für ein bestimmtes Projekt gelten." Das Projekthandbuch enthält somit die speziell für dieses Projekt geltenden Vereinbarungen und ergänzt ggf. das Projektmanagement-handbuch (welches nach DIN übergreifend für alle Projekte gültig ist)

• Engl.: project manual • Wird durch den Projektmanager zu Beginn des Projekts erstellt und an die

Projektteammitglieder (PTMs) verteilt • Darf nur zentral (durch den Projektmanager) verändert werden! • Enthält die Liste der Projektmitarbeiter, den (ungefähren) Zeitplan, die

Verantwortlichkeiten, den ersten Projektstrukturplan, die Dokumentations-struktur, allgemeine Richtlinien

• Ist kein rein statisches Dokument, sondern wird in regelmäßigen Intervallen aktualisiert

• Alternative Bezeichnung: Projektakte

Das Projekthandbuch



1.83 – 17.09.2012 Seite 88 von 228

PM Basis

1. Wann erfolgt der „eigentliche“ Projektstart? 2. Warum sollte ein Kick-Off-Meeting durchgeführt werden? Was

passiert ohne Kick-Off-Meeting? 3. Wann beginnen Stakeholder-, Qualitäts- und

Risikomanagement? 4. Welche Projektdokumente sind (minimal) in einem Projekt

notwendig? 5. Was ist der Inhalt des Projekthandbuchs?

Fragen zum Kapitel



1.83 – 17.09.2012 Seite 89 von 228

PM Basis

Teil II Te

il II

Seite 89-155

Teil II: Planen, Verfolgen, Steuern, Abschließen

Kapitel 6 Planungen im Projekt Kapitel 7 Projektcontrolling und Berichtswesen Kapitel 8 Projektabschluss


1.83 – 17.09.2012 Seite 90 von 228

PM Basis

Kapitel 6: Planungen im Projekt

Kapi

tel 6

• Der Planungsprozess (Grundsätzliches, Übersicht, Fallstricke bei der

Durchführung) • Der Projektmanagementplan (Beschreibung, Mögliche Elemente) • Der Projektstrukturplan (Übersicht, Darstellung, Zentraler Plan,

Beispiel 1-3, Anmerkungen, Vorgehen bei der Erstellung, Tipps, Übung, Checkliste, Fragen)

• Die Arbeitspakete (Grundsätzliches, Beschreibung, Arbeitspaketformular, Schätzungen, Schätzklausur)

• Die Vorgangsliste (Definition, Beispiel) • Vorgangsabfolgen (Grundlagen, Anordnungsbeziehungen, Beispiele

für Anordnungsbeziehungen) • Der Terminplan (Beschreibung, Einfache Gantt-Darstellung,

Komplexere Darstellung) • Der Kapazitätsplan (Beschreibung, Beispiel) • Der Kostenplan (Beschreibung, Beispiel) • Der Netzplan (Übersicht, Typen, Darstellung, Beispiel, Anmerkungen) • Planungssysteme: Anmerkungen • Tipps zum Kapitel • Fragen zum Kapitel

Seite 90-132

Teil II

6. 7. 8. Planungen im Projekt II.


1.83 – 17.09.2012 Seite 91 von 228

PM Basis

Mit dem Projektstart (mit der Unterzeichnung des Projektauftrags und während der Durchführung des Kick-Off-Meetings) beginnt die Planung des Projekts. Hierzu wird zunächst der Projektstrukturplan erstellt, der die Arbeitspakete als kleinste Einheiten beinhaltet. Die Arbeitspakete werden dann über die Vorgangsliste in eine logische Reihenfolge (mit zeitlichen Abhängigkeiten) gebracht. Aus der Vorgangsliste ergibt sich der (vorläufige) Terminplan, der wiederum als Basis für den Kapazitätsplan dient. Die Kosten und der Kostenverlauf werden abschließend im Kostenplan ermittelt. Sollte sich im Verlauf des Planungsprozesses zeigen, dass die ermittelten Werte nicht zu den Projekt-zielen passen, so müssen (und können) einzelne Planungsstufen erneut durchlaufen werden. Anmerkungen: • Vielfach („früher“) wurde das Planen eines Projekts mit Projektmanagement gleich

gesetzt, heute wird es als ein (wesentlicher) Bestandteil des PMs gesehen • Planungen werden heute zumeist toolgestützt, d.h. mit Projektmanagement-Soft-

ware(-systemen), durchgeführt

Der Planungsprozess (1/3): Grundsätzliches



1.83 – 17.09.2012 Seite 92 von 228

PM Basis

„Die Summe aller Pläne“ wird als Projekt-(management)-plan bezeichnet.

Der Planungsprozess (2/3): Übersicht


direkte Abfolge

Nebenschritteoptionale Rücksprünge


1.83 – 17.09.2012 Seite 93 von 228

PM Basis

• Die Schätzungen der Zeit und der Kosten sind zu optimistisch • Die Planung ist auf einen Endtermin ausgerichtet, ohne

Zwischenergebnisse zu berücksichtigen • Die Detailgenauigkeit ist ungenügend und vernachlässigt Aktivitäten • Die Pläne enthalten keine Fehlzeiten (Ferien, Meetings, Krankheit,

Weiterbildung) • Vergabe von Aufgaben an Personen, ohne diese vorher befragt zu haben • Mehrfachverplanung von Mitarbeitern • Der „kritische Pfad“ ist schon zu Beginn kritisch (siehe später) • Die Pläne sind in erster Linie Wunschpläne des Managements, nicht jedoch

der Mitarbeiter • (Das Planungstool ist unzureichend)

Der Planungsprozess (3/3): Fallstricke bei der Durchführung



1.83 – 17.09.2012 Seite 94 von 228

PM Basis

Nach PMI /PBG08-d/ ist der Projektmanagementplan „ein formelles geneh-migtes Dokument, in dem definiert ist, wie das Projekt ausgeführt, überwacht und gesteuert wird. Es kann in zusammengefasster Form oder detailliert sein und einen oder mehrere Managementpläne oder andere Planungsdokumente beinhalten.“ In der DIN 69901-5:2009 /DIN09/ wird hierfür der Begriff Projektplan verwendet, der die „Gesamtheit aller im Projekt vorhandenen Pläne“ umfasst. Wie verwenden hier immer den Begriff Projektmanagementplan für die „Summe aller Pläne im Projekt“. Der Projektmanagementplan … • liefert allen Beteiligten eine Abschätzung, was wann zu erfolgen hat, • ist jederzeit für die Projektmitglieder offen einsehbar und • hat eine vom Projekt abhängige, dann aber festgelegte Struktur.

Der Projektmanagementplan (1/2): Beschreibung



1.83 – 17.09.2012 Seite 95 von 228

PM Basis

Der Projektmanagementplan kann neben den, aus dem „klassischen“ Pla-nungsprozess entstehenden Dokumenten, auch weitere Elemente wie den Qualitätsplan, den Risikoplan oder den Beschaffungsplan enthalten.

Der Projektmanagementplan (2/2): Mögliche Elemente



1.83 – 17.09.2012 Seite 96 von 228

PM Basis

Der Projektstrukturplan (PSP, engl. Work Breakdown Structure, WBS) unterteilt das Projekt in einzelne, hierarchische Teilpakete. Der Projektstrukturplan muss bei jedem Projekt erstellt werden. Die DIN 69901-5:2009 /DIN09/ definiert den PSP wie folgt: „Der Projektstrukturplan ist eine vollständige, hierarchische Darstellung aller Elemente (Teilprojekte, Arbeitspakete) der Projektstruktur als Diagramm oder Liste.“

Der PMBOK Guide des PMI /PBG08/ stellt den PSP in als zentrales Element des Projekts dar und verweist auf die Liefergegenstände: Der Projektstrukturplan ist „eine an Liefergegenständen orientierte hierarch-ische Strukturierung der durch das Projektteam durchzuführenden Arbeit, um die Projektziele zu erfüllen und die erforderlichen Liefergegenstände zu erstellen. Er organisiert den gesamten Inhalt und Umfang des Projekts.“

Der Projektstrukturplan (1/12): Übersicht 1



1.83 – 17.09.2012 Seite 97 von 228

PM Basis

Die Elemente des Projektstrukturplans sind: • Gesamtprojekt oder Gesamtpaket • Teilprojekt oder Teilpaket (TP): Noch weiter zu untergliedernde Aufgabe

oder Phase • Arbeitspakete (AP): Kleinste, im PSP nicht mehr unterteilbare Unteraufgabe

oder Unteraktivität; AP können eigenverantwortlich durch organisatorische Einheiten bearbeitet werden; die Arbeitspakete definieren Liefergegen-stände (engl. Deliverables), deren Erfüllung/Erreichung überprüft werden kann

Es wird zwischen dem … • objektorientierten (auf den Gegenstand ausgerichtet), • funktionsorientierten (auf die (Linien-)Tätigkeit ausgerichtet) und • phasenorientierten (auf die Projektphasen ausgerichtet) PSP unterschieden (siehe nächste Folien). • Mischformen sowie Erweiterungen sind möglich

Der Projektstrukturplan (2/12): Übersicht 2



1.83 – 17.09.2012 Seite 98 von 228

PM Basis

Der Projektstrukturplan (3/12): Darstellung

Der PSP zeigt einen hierarchischen Aufbau, bei dem das Gesamtprojekt auf der obersten Ebene angeordnet wird, die Teilprojekte darunter und die Arbeitspakete auf der untersten Ebene. Die einzelnen Elemente erhalten eindeutige Nummern.


Projekt

...

...

Teilprojekt 3Teilprojekt 2Teilprojekt 1

AP 1.1

AP 1.2

AP 2.1

AP 1.3

AP 2.2

AP 3.1

AP 2.4

AP 2.3

AP 3.2


1.83 – 17.09.2012 Seite 99 von 228

PM Basis

Der Projektstrukturplan (4/12): Beispiel 1

Dies ist ein objektorientierter Projektstrukturplan!


AufstellortSoftwareHardware

Gehäuse

Netzteil

Motherboard

Büro

Schreibtisch

Grafikkarte

Festplatte

Betriebs-system

Office-Paket

Tools

Kommun.-software

2 3

2.1 3.1

3.22.2

2.3

2.4

1.3

1.4

1.5

1.2

1.1

1

PC


1.83 – 17.09.2012 Seite 100 von 228

PM Basis


Dies ist ein phasenorientierter Projektstrukturplan!


Genehmi-gungsplanung

Entwurfs-planung

Ausführ-ungsplanung

Einzug

Bauabnahme

Abrechnung

Überwachung

Ausführung

Beschaffung

0

2.1 3.1

3.22.2

2.3

2.4

1.3

1.2

1.1

Errichtung eines Wohngebäudes

Betriebsauf-nahmeRealisierungPlanung

1.3.1 Rohbau

1.3.2 Fenster

1.3.3 Dach

1.3.4 Sanitär

1 2 3


1.83 – 17.09.2012 Seite 101 von 228

PM Basis



objekt-orientiert

funktions-(= tätigkeits)orientiert

phasen-orientiert

gemischt-orientiert

Haus Haus

HausHaus

Keller DachErdgeschoss Erdarbeiten Tischler-arbeitenMauerarbeiten

Planung AbnahmeAusführung Planung Ausführung

Entwurf Statik Keller Dach


1.83 – 17.09.2012 Seite 102 von 228

PM Basis

Der Projektstrukturplan (7/12): Anmerkungen

Der Projektstrukturplan … • muss nicht grafisch dargestellt werden – eine

tabellarische Darstellung ist genauso gut • hat bereits eindeutige Nummern für die Teilprojekte und

Arbeitspakete (PSP-Code) • könnte auch als Mindmap dargestellt werden • verzeichnet nicht die notwendigen Ressourcen (Kosten,

Mitarbeiter, Material) • enthält keine zeitlichen Abhängigkeiten und Termine, ist

also eine statische Betrachtung • muss keine logischen Abhängigkeiten zwischen den

Arbeitspaketen enthalten • ist Basis für viele weitere Pläne, z.B. den Terminplan oder

Kostenplan • wird bei Bedarf im Projektverlauf angepasst; dies bedarf

aber der Genehmigung durch den Lenkungsausschuss



1.83 – 17.09.2012 Seite 103 von 228

PM Basis

• Der Projektstrukturplan sollte möglichst frühzeitig („zu Beginn des Projekts“) vorliegen

• Grundsätzlich kann nach einem Top-Down- oder einem Bottom-Up-Ansatz vorgegangen werden. Beim Top-Down-Ansatz wird das zu erstellende Produkt als Ganzes betrachtet und dann zergliedert (vorteilhaft bei neuen Produkten), beim Bottom-Up-Ansatz werden bereits bekannte Arbeitspakete (als Gerüst) aus Standardprojektstrukturplänen verwendet und dann ausgebaut

• Das „passende Schneiden“ von Arbeitspaketen ist nicht einfach. Achten Sie darauf, das a) die AP nicht zu groß werden und b) bei phasenorientierten PSP die AP auch in die einzelnen Phasen passen (bis auf übergreifende Themen)

• Extern zu vergebende Aufgaben müssen immer in eigenen AP untergebracht sein • Wenn die AP benannt sind, werden diese durchnummeriert (nach dem bereits

dargestellten Schema) und die Erstellung des PSP ist damit (zunächst) beendet • Nach der Erstellung des PSPs erfolgt die Zuordnung der AP zu den

Verantwortlichen, um dann dort weiter „runtergebrochen“ und spezifiziert zu werden • Es gilt die 100%-Regel: Alles, was im Projekt gemacht wird, steht im PSP. Nur das,

was im PSP steht, wird im Projekt auch gemacht. Alle AP zusammen ergeben 100 % des (Teil-)Projekts

Der Projektstrukturplan (8/12): Vorgehen bei der Erstellung



1.83 – 17.09.2012 Seite 104 von 228

PM Basis

Der Projektstrukturplan (9/12): Tipps

1. Erstellen Sie unbedingt einen Projektstrukturplan – am besten in Zusammenarbeit mit einigen (späteren) Teammitgliedern!

2. Klären Sie vorab genau die (zeitlichen wie inhaltlichen) Grenzen des Projekts

3. Planen Sie Zeit für die Erstellung des PSPs ein; für große Projekte kommen schnell mehrere Stunden zusammen!

4. Wenn möglich erstellen Sie den PSP an einer Metaplanwand, um so einen schnellen Gesamtüberblick zu erhalten

5. Vergeben Sie die Verantwortung für die Arbeitspakete (unabhängig von der Größe) an Einzelpersonen, nicht an Gruppen!

6. Bei der Zuordnung der Zuständigkeiten für die Bearbeitung der Arbeitspakete ist es sinnvoll, die potenziellen Verantwortlichen direkt zu befragen und nicht zu diktieren!

7. Verwenden Sie auf Arbeitspaket-Ebene aktive Formulierungen, so z.B. „Heizung einbauen“, „Heizung planen“ anstatt „Heizung“, um so Mehrdeutigkeiten zu vermeiden



1.83 – 17.09.2012 Seite 105 von 228

PM Basis

Der Projektstrukturplan (10/12): Übung

Erstellen Sie einen Projektstrukturplan für Ihr nächstes Projekt. Alternativ: Erstellen Sie einen Projektstrukturplan für die Neukonstruktion einer Kaffeemaschine (bis zur Serienfertigung).

Dauer: 40 Min.




1.83 – 17.09.2012 Seite 106 von 228

PM Basis

Der Projektstrukturplan (11/12): Checkliste



Kennt jeder im Team die Bedeutung des Projektstrukturplans?

Wurde auf Standardstrukturpläne zurückgegriffen?

Waren alle (erforderlichen) Experten an der Erstellung beteiligt?

Wurde der Strukturplan auf Vollständigkeit überprüft?(100%-Regel)

Sind die Bezeichnungen der Arbeitspakete allgemein verständlich und eindeutig gewählt? (Aktive Formulierung?)

Wird das Projektziel mit den aufgeführten Arbeitspaketen tatsächlich erreicht?

Wurden auch allgemeine Tätigkeiten (z.B. Meetings oder Koordinationsaufgaben) eingeplant?

Frage MaßnahmenJa Nein Offen


1.83 – 17.09.2012 Seite 107 von 228

PM Basis

Der Projektstrukturplan (12/12): Fragen

1. Wann wird der Projektstrukturplan erstellt? 2. Wer erstellt den Projektstrukturplan? 3. Wie genau und umfassend sollte der Projektstrukturplan (in

den einzelnen Phasen des Projekt) sein? 4. Welche Arten von Projektstrukturplänen kennen Sie? Was

sind die Vor- und Nachteile? 5. Welche Vorteile bietet die grafische Repräsentation

gegenüber der tabellarischen? 6. Warum sollten Sie bei den AP-Verantwortlichkeiten nur

Einzelpersonen, nicht aber Gruppen einsetzen? 7. Wann erfolgt die Detaillierung bei den AP? Wie können

Schätzungen für die AP abgeben werden, die bereits sehr früh benötigt werden (z.B. bei der Größenabschätzung)?

8. Wie wird der PSP in Ihrer PM-Software untergebracht? 9. Wird der Projektabschluss mitgeplant?



1.83 – 17.09.2012 Seite 108 von 228

PM Basis

Die Arbeitspakete (engl. Work Packages, WP) bilden die kleinsten, nicht mehr zu unterteilende Teilaufgaben im Projekt. Sie kommen aus dem Projekt-strukturplan und werden i.A. über Arbeitspaketformulare oder direkt über PM-Systeme beschrieben und erfasst. Die einzelnen Arbeitspakete werden AP-Verantwortlichen zugeordnet und durch diese weiterentwickelt, indem weitere Aktivitäten, benötigte Ressourcen und auch die Kosten ermittelt werden. Die Arbeitspakete bilden die Basis für alle weiteren Tätigkeiten im Projekt (Planungen, Schätzungen, Fortschrittskontrolle, Vorgangslistendarstellung). Arbeitspakete sind an Liefergegenständen ausgerichtet. Nach DIN 69901-5:2009 /DIN09/ ist ein Arbeitspaket eine „in sich geschlos-sene Aufgabenstellung innerhalb eines Projekts, die bis zu einem festgelegten Zeitpunkt mit definiertem Ergebnis und Aufwand vollbracht werden kann.“

Die Arbeitspakete (1/5): Grundsätzliches



1.83 – 17.09.2012 Seite 109 von 228

PM Basis

Arbeitspakete enthalten: • Eine eindeutige Id innerhalb des PSPs (PSP-Code) • Eine eindeutige Bezeichnung (AP-Bezeichnung) • Einen Verantwortlichen (AP-Verantwortlicher) • Eine Dauer • Einen Aufwand • (Zeitliche Abhängigkeiten) • (Logische Abhängigkeiten)

Merkmale von AP: • Sie werden ggf. noch auf Aktivitätenebene unterteilt • Sie bilden die Basis aller weiteren Planungen und Schätzungen sowie des

Controllings

Größe: • „So, dass einfach verfolgt werden kann“: Maximal 10 % des Gesamtprojekts oder

maximal 20 Arbeitstage o.ä. (auch: 80-Stunden-Regel: „Nicht weniger als 80 Stunden“)

Die Arbeitspakete (2/5): Beschreibung



1.83 – 17.09.2012 Seite 110 von 228

PM Basis

Das hier dargestellte Formular dient nur zur Arbeitspaket-Feinplanung; zur Nachverfolgung sollte das Formular erweitert werden.

Die Arbeitspakete (3/5): Arbeitspaketformular


AP-Verantwortlicher

Projekt

AP-Bezeichnung

Voraussetzungen für das Arbeitspaket

Zu erbringende Ergebnisse

Aktivitäten

1.

2.

3.

PSP-Code

Datum Version Status Erstellt durch

Abhängige Arbeitspakete

Benötigte Ergebnisse anderer Arbeitspakete

Gesamtdauer AP Gesamtaufwand AP Gesamtkosten AP

Projekt-Id

4.


1.83 – 17.09.2012 Seite 111 von 228

PM Basis

Bei den Arbeitspaketen müssen (zumindest) Dauer, Aufwand und Kosten geschätzt werden. Die Schätzung sollte möglichst genau sein, da sie den kompletten Projekt-verlauf definiert. Typischerweise wird die Schätzung in einer Schätzklausur (siehe nächste Folie) durch einige oder alle Mitglieder des Projektteams durchgeführt. Typische Schätzverfahren sind: • Expertenschätzung: Die Schätzgrößen werden durch einen oder mehrere Experten geschätzt • Analogiemethode: Aus bereits beendeten Projekten (mit entsprechender Ähnlichkeit) werden

die Größen übernommen • Kennzahlenmethode: Aus bereits beendeten Projekten werden Kennzahlen ermittelt und den

Kennzahlen des eigenen Projekts gegenübergestellt • Brainstorming: Alle Schätzer setzen sich zusammen und tauschen sich über die Größen aus;

wird oftmals zur Detailschätzung benutzt • Drei-Punkt-Schätzung oder PERT-Schätzung (aus der Program Evaluation & Review

Technique stammend): Schätzungen werden mit Wahrscheinlichkeiten belegt und die Größen nach folgender Gleichung geschätzt:

Die Arbeitspakete (4/5): Schätzungen

oW + 4*mW + pW 6

Wert = pW = pessimistischter Wert mW = mittlere Wahrscheinlichkeit oW = optimistischter Wert



1.83 – 17.09.2012 Seite 112 von 228

PM Basis

Die DIN 69901-3:2009 /DIN09/ definiert die Ablaufschritte einer Schätzklausur wie folgt: • Auswahl der Experten, welche die Schätzung durchführen; • Verteilung der Informationen an die Experten; • (Vorab-)Schätzung des Aufwands durch die Experten; • Gemeinsame Durchsprache der Schätzergebnisse, insbesondere von

Abweichungen (Achtung, auch bei Prämissen und Annahmen); • Festlegung des gemeinsam getragenen Schätzergebnisses sowie der

gemeinsamen Prämissen.

Die Arbeitspakete (5/5): Schätzklausur



1.83 – 17.09.2012 Seite 113 von 228

PM Basis

Die Vorgangsliste (engl. activity list): Die Vorgangsliste ist eine tabellarische Aufzählung von Vorgängen eines Projekts (auch Projektprozesse genannt). Typischerweise werden die Arbeitspakete aus dem Projektstrukturplan zu Vorgängen der Vorgangsliste, indem Dauer, Aufwand, Vorgänger (als PSP-Code) und Nachfolger (auch als PSP-Code) notiert werden. Hierdurch werden die logischen Abhängigkeiten aufgezeigt.

Wenn man der Vorgangsliste weitere Vorgangseigenschaften hinzufügt, so kann sie auch für weitere Zwecke verwendet werden, so z.B. für das Controlling.

Die Vorgangsliste (1/2): Definition


PSP-Code Dauer Vorgänger NachfolgerAufwandVorgangsname

AP x.y Vorgang x.y


1.83 – 17.09.2012 Seite 114 von 228

PM Basis

Die Vorgangsliste (2/2): Beispiel

An diesem Beispiel erkennt man, dass die Vorgangsliste schnell sehr lang werden kann.


PSP-Code

Entwurfsplanung erstellen 5 PT5 Tage1.1

Genehmigungsplanung durchführen 2 PT10 Tage1.2

Rohbau planen 4 PT10 Tage1.3.1

Fenster planen 1 PT10 Tage

Dach planen 2 PT10 Tage

Sanitär planen

Ausführung begleiten

1.2;-

1.3.1; 1.3.21.1

1.3.2

1.3.3

1.3.4

Beschaffung durchführen

2.1

2.2

Fortschritt überwachen2.3

Abrechnung überprüfen2.4

10 Tage 2 PT

90 Tage 10 PT

60 Tage 10 PT

90 Tage 5 PT

30 Tage 5 PT

2.11.3.1

1.3.2; 1.3.31.2

1.2 -

Realisierung2.0

1.3.1 2.1; 2.2

1.3.3, 1.3.4

1.3.4

2.1

2.1, 2.2

2.3; 2.4

2.4

-

-

Planung1.0

1.3 Ausführungsplanung

Vorgangsname Dauer Vorgänger NachfolgerAufwand


1.83 – 17.09.2012 Seite 115 von 228

PM Basis

Aus der Vorgangsliste kann auch ohne Verwendung der Dauer oder Aufwände eine logisch-zeitliche Abfolge der Vorgänge grafisch abgeleitet werden: Dies ist der sogenannte Ablaufplan (der heute weniger gebräuchlich ist). Dabei gibt es zwei typische Abfolgen: Die serielle und die parallele.

In der Praxis treten Vorgangsabfolgen auf, die nicht auf reinen Ende-Anfang-Beziehungen der Vorgänge basieren; auf der nächsten Folie sind alle normierten Abfolgen nach DIN und PMI dargestellt.

serielle Abfolge:

parallele Abfolge:

Vorgangsabfolgen (1/3): Grundlagen


Vorgang 1 Vorgang 2 Vorgang 3

Vorgang 1 Vorgang 5

Vorgang 4

Vorgang 2 Vorgang 3


1.83 – 17.09.2012 Seite 116 von 228

PM Basis

Vorgangsabfolgen (2/3): Anordnungsbeziehungen


Vorgang 1 Vorgang 2

EA = Ende-Anfang

Vorgang 1 Vorgang 2

AA = Anfang-AnfangDIN: NF - NormalfolgePMI: FS - Finish-to-Start

DIN: AF - AnfangsfolgePMI: SS - Start-to-Start

• Vorgang 2 kann erst beginnen, wenn Vorgang 1 abgeschlossen ist.

• Vorgang 1 muss abgeschlossen sein, bevor Vorgang 2 beginnen kann.

• Vorgang 2 kann erst beginnen, wenn Vorgang 1 begonnen hat.

• Vorgang 1 muss begonnen haben, bevor Vorgang 2 beginnen kann.

Vorgang 1 Vorgang 2

DIN: EF - EndfolgePMI: FF - Finish-to-Finish

• Vorgang 2 kann erst abgeschlossen werden, wenn Vorgang 1 abgeschlossen ist.

• Vorgang 1 muss abgeschlossen sein, bevor Vorgang 2 enden kann.

EE = Ende-Ende AE = Anfang-Ende

Vorgang 1 Vorgang 2

DIN: SF - SprungfolgePMI: SF - Start-to-Finish

• Vorgang 2 kann erst abgeschlossen werden, wenn Vorgang 1 beginnt.

• Vorgang 1 muss begonnen haben, bevor Vorgang 2 abgeschlossen werden kann.

am häufigsten!

eher selten!


1.83 – 17.09.2012 Seite 117 von 228

PM Basis

Vorgangsabfolgen (3/3): Beispiele für Anordnungsbeziehungen


Vorgang 1 Vorgang 2

EA = Ende-Anfang

Vorgang 1 Vorgang 2

AA = Anfang-AnfangDIN: NF - NormalfolgePMI: FS - Finish-to-Start

DIN: AF - AnfangsfolgePMI: SS - Start-to-Start

• Der Rohbau muss fertig sein, bevor das Dach aufgebaut werden kann.

• Die Software muss getestet sein, bevor sie eingesetzt wird.

• Der Bau kann begonnen werden, wenn die Materialien geliefert wurden.

• Mit Beginn des Codierens kann mit dem Testen begonnen werden.

Vorgang 1 Vorgang 2

DIN: EF - EndfolgePMI: FF - Finish-to-Finish

• Die Dokumentation kann erst abgeschlossen werden, wenn das Produkt fertig getestet wurde.

• Die Heizungsanlage kann erst in Betrieb genommen werden, wenn die Elektrik fertig ist.

EE = Ende-Ende AE = Anfang-Ende

Vorgang 1 Vorgang 2

DIN: SF - SprungfolgePMI: SF - Start-to-Finish

• Die eigene Stromversorgung darf erst in Betrieb genommen werden, wenn die externe Strom-versorgung aufgenommen wurde.

• Die alte Anlage darf erst außer Betrieb gehen, wenn die neu gebaute Ersatzanlage angelaufen ist.


1.83 – 17.09.2012 Seite 118 von 228

PM Basis

Im Terminplan (oder auch Projektterminplan, engl. project schedule) werden die Vor-gänge aus der Vorgangsliste in eine zeitliche Reihenfolge gebracht. Die Vorgänge werden durch Balken wiedergegeben, deren Länge die Zeitdauer repräsentieren. Die Abhängigkeiten werden durch Pfeile symbolisiert. Hiermit lässt sich recht einfach eine Termin(gesamt)planung durchführen. Der Projektterminplan wird oftmals mit dem Projektablaufplan gleichgesetzt, wobei der Projektablaufplan keine konkreten Start- und Endtermine enthalten muss. Die Begriffe Gantt-Plan oder Balkenplan (engl. Time-Scaled Schedule Network Diagram nach PMI) sind als Synonym recht häufig in der Literatur zu finden. In den gängigen Software-Planungssystemen werden dem Terminplan Kapazitäten und Meilensteine hinzugefügt: damit wird der Terminplan zum zentralen Plan; der Termin-plan ist ein Vorgangsknotennetzplan (siehe später).

Achtung: Der Terminplan berücksichtigt (zunächst) nicht die Aufwände!

Der Basisplan (engl. Baseline) ist der Terminplan, der bei Projektstart vorliegt und der die Grundlage aller Berechnungen während des Projektverlaufs bildet.

Der Terminplan (1/3): Beschreibung



1.83 – 17.09.2012 Seite 119 von 228

PM Basis

Der Terminplan (2/3): Einfache Gantt-Darstellung


1 2 3 4 5 6 7 8 9 10 11 12 13

Vorgang 1

Vorgang 2

Vorgang 3

Vorgang 4

Vorgang 5

Vorgang 6

Vorgang 7

Zeitabschnitte


1.83 – 17.09.2012 Seite 120 von 228

PM Basis

Der Terminplan (3/3): Komplexere Darstellung


PTM2

PTM3

PTM2

PTM3

PTM1

PTM2

PTM1

2 3 4 5 6 7 8 9 10 11 12 131

Vorgang 1

Vorgang 2

Vorgang 3

Vorgang 4

Vorgang 5

Vorgang 6

Vorgang 7

Kalenderwoche

1

Id Vorgangs-name

2

3

4

5

6

7

Ver-antw


1.83 – 17.09.2012 Seite 121 von 228

PM Basis

Mit dem Kapazitätsplan (auch Ressourcen- oder Einsatzmittelplan) wird ermittelt, welche Kapazitäten (im Allgemeinen Mitarbeiter und Produktions-ressourcen wie Material, Werkzeuge und Maschinen) wann benötigt werden. Er leitet sich aus dem Terminplan ab, indem die jeweils benötigten Ressourcen notiert werden (bei den Mitarbeitern ist dies teilweise indirekt schon über den Aufwand geschehen). Erst nach der Erstellung des Kapazitätsplans kann festgestellt werden, ob der Terminplan realistisch ist, denn erst hier fällt auf: • Wenn Mitarbeiter in Teilbereichen mehrfach verplant sind • Wenn die ermittelte benötigte Kapazität größer ist als die Gesamtzahl an

Mitarbeitern oder Ressourcen

Der Kapazitätsplan (1/2): Beschreibung



1.83 – 17.09.2012 Seite 122 von 228

PM Basis

Der Kapazitätsplan (2/2): Beispiel


PTM4

2 3 4 5 6 7 8 9 10 11 12 131

PTM1

PTM1

PTM1

PTM2

PTM2

PTM3

P3

PTM3

PTM3

PTM3

PTM2

PTM2

PTM2

PTM2

PTM3

P2

PTM2

PTM2

P3 P4

PTM1

PTM3

PTM1

PTM1

Kalenderwoche


1.83 – 17.09.2012 Seite 123 von 228

PM Basis

Der Kostenplan (engl. cost baseline, nach PMI) stellt den Kostenverlauf während des Projekts dar. Hierzu werden die aus dem Kapazitätsplan bekannten Ressourcen mit den entsprechenden Kosten (pro Ressource) verrechnet. Es ergibt sich, welche Kosten pro Zeitabschnitt entstehen; kumuliert über die Gesamtzeit wird der Kostenverlauf im Projekt ermittelt. Nach DIN 69901-5:2009 /DIN09/ ist der Kostenplan (engl. cost plan) definiert als „Darstellung der voraussichtlich für das Projekt anfallenden Kosten, welche auch den Kostenverlauf enthalten kann.“ Schwierigkeiten bei der Erstellung des Kostenplans: • Fix- und Gemeinkosten sind den zeitlichen Vorgängen teilweise schwer

zuordbar • In einigen Unternehmen ist es nicht erlaubt, die Kostensätze interner oder

externer Mitarbeiter öffentlich zu machen. Damit hat der Kostenplan nur eingeschränkte Aussagekraft

Der Kostenplan (1/2): Beschreibung



1.83 – 17.09.2012 Seite 124 von 228

PM Basis

Der Kostenplan (2/2): Beispiel


Kalenderwoche2 3 4 5 6 7 8 9 10 11 12 131

0100

300

500

800

1.000

700600

900

1.100

200

400

Kosten


1.83 – 17.09.2012 Seite 125 von 228

PM Basis

• Der Netzplan (engl. network) ist eine grafische Darstellung von Vorgängen (aus der Vorgangsliste)

• Laut DIN 69900:2009 ist er eine „graphische oder tabellarische Darstellung einer Ablaufstruktur, die aus Vorgängen bzw. Ereignissen und Anordnungs-beziehungen besteht“

• Anders als beim reinen Terminplan wird nicht die Zeit visualisiert, sondern auf die logischen Abhängigkeiten Wert gelegt

• Der Netzplan erhöht die Planungssicherheit und hilft, den „Dominoeffekt von Terminverzögerungen“ zu verhindern

Der Netzplan (1/5): Übersicht


V1

V2

V3

V4

V5


1.83 – 17.09.2012 Seite 126 von 228

PM Basis

Es wird generell zwischen den folgenden drei Netzplanarten unterschieden:

Der Netzplan (2/5): Arten


Vorgangspfeilnetzplan(Activity on Arrow)

Vorgangsknotennetzplan(Activity on Node)

Ereignisknotennetzplan

Vorgänge: KnotenAbhängigkeiten: PfeileEreignisse: entfallen

Vorgänge: PfeileAbhängigkeiten: entfallenEreignisse: Knoten

Vorgänge: entfallenAbhängigkeiten: PfeileEreignisse: Knoten

Vorgang

Ereignis Ereignis Ereignis EreignisVorgangVorgang

Abhängig-keit

Kürzel VKN (AON) VPN (AOA) EKN

Verwendungin allen gängigen Büchern

und Software-Program-men; dies ist Standard!

seltenselten

Beschrei-bung

Darstellung

Abhängig-keit


1.83 – 17.09.2012 Seite 127 von 228

PM Basis

In der Praxis wird die Darstellungsform des Vorgangknotennetzes (VKN) am häufigsten genutzt. Hierbei werden notiert: • Vorgangsname • Code: eindeutiger Code für diesen Vorgang • Dauer: benötigte Zeit für diesen Vorgang • FAZ = frühester Anfangszeitpunkt • SAZ = spätester Anfangszeitpunkt • FEZ = frühester Endzeitpunkt • FEZ = spätester Endzeitpunkt

Der Netzplan (3/5): Darstellung


Vorgangsname

SAZ SEZDauer

FAZ FEZCode

GUI-Beschreibung

15.01

14.02

12.02

14.03

06.102

4 Wochen


1.83 – 17.09.2012 Seite 128 von 228

PM Basis

Hier ist ein einfaches Beispiel eines Vorgangsknotennetzes (VKN) dargestellt. Die die konkreten Start- und Endzeitpunkte zu den Vorgängen werden in den einzelnen Knoten festgehalten. Die rot eingefärbte Vorgangsfolge stellt den „kritischen Pfad“ dar: Ein Verschieben der Vorgänge auf diesem Pfad bewirkt eine zeitliche Verschiebung des Gesamtprojekts.

Der Netzplan (4/5): Beispiel


Küchenplan erstellen

30.06

1 Tag

A

14.07

01.07

15.07

Neue Küche inbetriebnehmen

30.07

1 Tag

F

13.08

31.07

14.08

Auswahl treffen und bestellen

01.07

1 Wo

B

15.07

08.07

22.07

Alte Küche abbauen

01.07

1 Tag

D

11.08

02.07

12.08

Anlieferung koordinieren

08.07

3 Wo

C

22.07

29.07

12.08

Neue Küche einbauen

29.07

1 Tag

E

12.08

30.07

13.08


1.83 – 17.09.2012 Seite 129 von 228

PM Basis

Die Netzplantechnik ist die Grundlage für folgende Methoden zur Optimierung des Projektplans: • CPM – Critical Path Method (Kritischer-Weg-Methode); hier wird aufgrund der

Dauer der einzelnen Aktivitäten die Gesamtprojektdauer ermittelt. Hieraus ergibt sich der kritische Weg, der eine Abfolge von kritischen Vorgängen mit der minimalen Projektdauer darstellt. Der kritische Pfad muss besonders intensiv überwacht werden

• PERT – Program Evaluation and Review Technique; hier werden statt fest vorgegebener Vorgangsdauern variable Dauern mit Wahrscheinlichkeiten vorgegeben

Die Netzplantechnik lässt sich für große Projekte nur mit entsprechender Software einsetzen. Die Software kann dann zumeist auch die Darstellungsformen (= unter-schiedliche Pläne) ineinander überführen.

Der Netzplan (5/5): Anmerkungen

Zur Netzplantechnik gibt es eine eigenständige Präsentation des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/_pdf/peco-pm-netzplantechnik.pdf frei verfügbar ist.


https://www.peterjohann-consulting.de/_pdf/peco-pm-netzplantechnik.pdf

https://www.peterjohann-consulting.de/_pdf/peco-pm-netzplantechnik.pdf


1.83 – 17.09.2012 Seite 130 von 228

PM Basis

Heute werden die Planungen meistens mit entsprechenden Softwaresystemen (PMS = Projektmanagementsysteme) durchgeführt. Dabei wird meistens direkt – ohne Erstellung des Projektstrukturplans – der Terminplan mit den einzelnen Vorgängen sowie den Meilensteinen erstellt. Daraus ergeben sich automatisch der Projektstrukturplan, die Vorgangsliste, der Kapazitäts- und auch der Kostenplan. Dieser gleichzeitige Blick auf alle Pläne erleichtert das Optimieren des Gesamtplans. Reine Netzpläne werden heute nur noch selten verwendet, da diese sehr aufwendig zu erstellen sind und sich daher nur für große Projekte lohnen. Dennoch sind sie für die Optimierung von großen Systemen unerlässlich, da hier die Algorithmen aus der Graphentheorie angewandt werden können.

Planungssysteme: Anmerkungen



1.83 – 17.09.2012 Seite 131 von 228


1. Nehmen Sie sich Zeit, um den Projektstrukturplan (am besten mit dem Projektkernteam zusammen) zu erstellen

2. Ihre Pläne müssen im Projektverlauf überprüft und gege-benenfalls angepasst werden können. Achten Sie daher auf eine Darstellung, die für das Controlling verwendbar ist



1.83 – 17.09.2012 Seite 132 von 228


1. Nennen Sie die Planungsstufen und Dokumente in der zeitlichen Abfolge!

2. Warum enthält der Projektstrukturplan keine logischen und zeitlichen Abhängigkeiten?

3. Wie groß sollte ein Arbeitspaket sein? 4. Was ist der Unterschied zwischen Dauer und Aufwand (eines

Arbeitspakets)? 5. Welche Schätzmethoden (zur Aufwandsabschätzung) gibt es? 6. Warum muss oftmals nach der (ersten) Kapazitätsplanung zur

Terminplanung zurückgegangen werden?



1.83 – 17.09.2012 Seite 133 von 228

PM Basis

Kapitel 7: Projektcontrolling und Berichtswesen

Kapi

tel 7

• Projektcontrolling: Beschreibung • Ein Controlling-Regelkreis • Was wird controlled? • Beispiel 1: Ampelreport • Beispiel 2: Meilensteintrendanalyse • Beispiel 3: Abweichungen im Terminplan • Typische Fehler beim Projektcontrolling • Was sind Berichte? • Ein Berichtsplan: Beispiel • Tipps zum Kapitel • Fragen (zum Projektcontrolling)

Seite 133-144

Zum Projektcontrolling sowie zum Berichtswesen gibt es eigenständige Präsentationen des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/praesentationen frei herunterladbar sind.

Teil II

6. 7. 8. Projektcontrolling und Berichtswesen II.



1.83 – 17.09.2012 Seite 134 von 228

PM Basis

Nach DIN 69901-5:2009 /DIN09/ (in Anlehnung an einen Regelkreis) ist die Aufgabe des Projektcontrollings: „Sicherstellung des Erreichens aller Projektziele durch Ist-Datenerfassung, Soll-Ist-Vergleich, Analyse der Abweichungen, Bewertung der Abweichungen gegebenenfalls mit Korrekturvorschlägen, Maßnahmenplanung, Steuerung und Durchführung der Maßnahmen.“

Controlling = Messen + Steuern

Minimal werden die Parameter Leistung, Aufwand und Zeit (aus dem magischen Dreieck) im sogenannten Ampelreport controlled. Es gibt jedoch viele weitere Parameter, die verfolgt werden sollten.

Projektcontrolling: Beschreibung

Basisbegriffe: • Plan-Werte: Ursprünglich geplante Werte für das Projekt; erstellt (und gültig) bei

Projektbeginn • Ist-Werte: Tatsächlich erreichte Werte zu einem bestimmten Zeitpunkt

(typischerweise zu den Meilensteinen oder Berichtszeitpunkten) • Soll-Werte: Angepasste Planwerte zu einem bestimmten Zeitpunkt



1.83 – 17.09.2012 Seite 135 von 228

PM Basis

Hier ist ein typischer Controlling-Regelkreis dargestellt, wie er vielfach in Projekten Verwendung findet.

Ein Controlling-Regelkreis


Soll-Werte

Kennzahlen-system

Projekt

MaßnahmenAnalyse

Ist-Werte


1.83 – 17.09.2012 Seite 136 von 228

PM Basis

Folgende Werte können im Projektverlauf controlled werden: • Kosten • Termine • Kapazitäten • Umfang • Qualität • Risiken • Änderungen • Fehler • Fertigstellungsgrad • Zahlungen Die Basis des Projektcontrollings sind die Arbeitspakete des Projektstrukturplans. Deshalb müssen bei der Bearbeitung der AP die wesentlichen Informationen bereitgestellt werden. Faustregel: „Alles, was geplant wird, wird auch controlled.“ Auf den folgenden Folien sind drei Beispiele für Controlling-Übersichten dargestellt.

Was wird controlled?



1.83 – 17.09.2012 Seite 137 von 228

PM Basis

Beispiel 1: Ampelreport

Der Ampelreport liefert auf Basis des „magischen Dreiecks“ eine schnelle Aussage über den Gesamtzustand des Projekts.

Die Pfeile zeigen die Veränderung gegenüber dem letzten Status-bericht an (verbessert, unverändert, verschlechtert)


Verbesserung durch Reduzierung

des Arbeits-ergebnisses; daher jetzt grün statt gelb

Arbeitsergebnis kann Qualitätsstandard

nicht mehr erfüllen, jetzt rot statt gelb

Zeit(Termin)

Ergebnis,Leistung

(Qualität, Umfang)

Aufwand(Kosten)

Termin noch immer kritisch


1.83 – 17.09.2012 Seite 138 von 228

PM Basis

Beispiel 2: Meilensteintrendanalyse

Die Meilenstein-trendanalyse liefert einen schnellen Überblick, wie die gut die geplanten Meilensteintermine eingehalten werden.


Meilenstein-Termine

Berichts-zeitpunkte06 04

06

07

08

09

10

11

12

2013

2014

01

02

03

04

05

07 08 09 11 01 02 03 05 06

20142013

aktueller Berichtszeitpunkt

06

10 12

Kurve geht nach unten: Termin voreilend

Kurve geht nach oben: Termin nacheilend

Kurve verläuft horizontal: Termin wird eingehalten

Trifft ein Meilenstein auf die Diagonale, so wurde

der Termin erreicht

Analyse

Design

Realisierung

Abnahme


1.83 – 17.09.2012 Seite 139 von 228

PM Basis

Über eine (genaue) Betrachtung der Vorgänge im Terminplan lassen sich Ab-weichungen erkennen, die als Basis für genauere Planungen herangezogen werden können.

Beispiel 3: Abweichungen im Terminplan


2 3 4 5 6 7 8 9 10 11 12 131

Vorgang 1

Vorgang 3

Vorgang 4

Vorgang 5

Vorgang 2

Woche Heute

1

Id Vorgangs-name

2

3

4

5 Plan/Soll

Ist


1.83 – 17.09.2012 Seite 140 von 228

PM Basis

• Statt auf den Projektfortschritt wird nur noch auf den Projektplan geachtet • Es werden die Messgrößen nicht zeitnah zur Verfügung gestellt • Zwischen Messung und Steuerung ist ein zu großer zeitlicher Abstand • Es werden die falschen Messgrößen verwendet • Die Granularität der Messgrößen ist falsch gewählt • Projektcontrolling verkommt zu reinem Kostencontrolling (da dies

besonders einfach für Controller ist) • Es wird keine Zeit für das Controlling eingeplant • Aus dem Personalwesen abgeleitete Größen bedürfen besonders sensibler

Betrachtung, da sie im Allgemeinen nicht öffentlich sind • Es wird oft verwechselt: Der Projektcontroller ist nicht der Projektmanager

und zeigt nur die Schwachstellen auf – die Beseitigung der Schwachstellen ist Aufgabe des Projektmanagers

• Nichtbeachtung der Verbindlichkeit von Terminzusagen: Beim Überschreiten der Termine werden keine Gegenmaßnahmen eingeleitet

Typische Fehler beim Projektcontrolling



1.83 – 17.09.2012 Seite 141 von 228

PM Basis

Das Projektberichtswesen … • stellt sicher, dass allen Projektbeteiligten jederzeit die wesentlichen Informationen

aufbereitet und bereitgestellt werden. /Litke05/ • gleicht Informationsasymmetrien zwischen den Projektbeteiligten aus. /Jenny09/ • ist „verwandt“ mit dem Kommunikations- und Informationswesen sowie dem

Stakeholdermanagement. • benennt die (notwendigen) Berichte und die möglichen Empfänger im Berichtsplan. Der Berichtsplan beantwortet die Fragen: • Wer? • Mit wem? • Worüber? • Wie oft? • In welcher Form? • Womit? • (Und warum?)

Was sind Berichte?



1.83 – 17.09.2012 Seite 142 von 228

PM Basis

Ein Berichtsplan: Beispiel


Projekt-Newsletter

Projektabschluss-bericht

Bericht

Projektstatusbericht

Ersteller Empfänger Form, Turnus Ablage

Projektmanager

Projektmanager

Projektmanager

Lenkungsausschuss Projekt-Archiv

Projektteam

AP-Fortschrittsbericht ProjektmanagerAP-Verantwortlicher schriftlich,

wöchentlich

-schriftlich,wöchentlich

schriftlich,monatlich

Qualitätsbericht Qualitäts-Verantwortlicher Projektmanager

Lenkungsausschuss

schriftlich,wöchentlich

schriftlich,wöchentlich

Vorlage?

Ja

Nein

Ja internesArchiv

Projekt-ArchivJa

Ja Projekt-Archiv

Fortschrittsbericht Jaschriftlich,wöchentlichProjektmanager Sponsor,

ProjektteaminternesArchiv

Risikobericht Projektmanager Sponsor,Projektteam Jaschriftlich,

wöchentlichinternesArchiv

Fehlerbericht Jeder Jaschriftlich,sofort bei Bedarf

internesArchivProjektmanager

Sofortbericht Jeder Neinmündlich,sofort bei Bedarf -Projektmanager


1.83 – 17.09.2012 Seite 143 von 228


1. Erstellen Sie recht frühzeitig den Berichtsplan und überprüfen Sie, ob er zu Ihrem Projekt passt und reduzieren Sie ihn gegebenenfalls

2. Beachten Sie die Vorlaufzeit (und den Aufwand) bei der Erstellung von Berichten und bedenken Sie, dass das „Abliefern von Zahlen“ nicht die Lieblingsbeschäftigung von Projektmitarbeitern ist

3. Nutzen Sie (Standard-)Tools für das Controlling, die eventuell schon in Ihrem beruflichen Umfeld vorhanden sind



1.83 – 17.09.2012 Seite 144 von 228

PM Basis Fragen (zum Projektcontrolling)

1. Warum wird Projektcontrolling durchgeführt? 2. Wer führt das Projektcontrolling durch? 3. Wie viel Prozent Ihrer Arbeitszeit sollte für das

Projektcontrolling verwendet werden? 4. Was ist in Ihrem Umfeld (minimaler) Inhalt des

Projektstatusberichts?



1.83 – 17.09.2012 Seite 145 von 228

PM Basis

Kapitel 8: Der Projektabschluss

Kapi

tel 8

• Definition • Lessons Learned • Die Abschlusssitzung • Der Projektabschlussbericht (Aufbau und Inhalt, Formular) • Das Abnahmeprotokoll (Aufbau und Inhalt, Formular) • Checkliste: Kann das Projekt abgeschlossen werden? • Tipps zum Kapitel • Fragen zum Kapitel

Seite 145-155

Teil II

6. 7. 8. Der Projektabschluss II.


1.83 – 17.09.2012 Seite 146 von 228

PM Basis

Ein Projekt ist im Normalfall dann abgeschlossen, wenn das Projektziel erreicht ist; es folgen dann … • die Übergabe des Ergebnisses/Produkts an den Auftraggeber, • die Projektabschlusssitzung (für das Projektteam), • der Projektabschlussbericht (für das Management) und • die Auflösung des Projektteams und der Projektgremien. Beim Abbruch wegen Nichterreichung der Ziele sollte eine „Post-Mortem-Analyse“ vorgenommen werden, in der die Ursachen für das Scheitern analysiert werden. Beim Projektabschluss sollten das erworbene Wissen und die gewonnenen Erfahrungen für weitere Projekte gesichert werden. Hierzu werden neben dem Abschlussbericht die sogenannten „Lessons Learned“ weitergegeben – hierfür werden Methoden des Wissensmanagements verwendet. Aber (leider) – der „Normalfall“: „Projekte lernen schlecht“!

Definition



1.83 – 17.09.2012 Seite 147 von 228

PM Basis

Die Wissenssicherung bei Abschluss eines Projekts stellt häufig ein Problem dar. Das Sichern aller Dokumente und Berichte des Projekts liefert noch keinen Nutzen für nachfolgende Projekte – hierzu müssen die „wesentlichen Merkmale und Erkenntnisse“ aus dem abzuschließenden Projekt extrahiert und für Nachfolgeprojekte zugreifbar gemacht werden.

Lessons Learned


Projekt A

Projekt B Start

Durch- führung Abschluss

Durch- führung Planung

Lessons Learned

...

...


1.83 – 17.09.2012 Seite 148 von 228

PM Basis

Die förmliche Projektabschlusssitzung wird auch als „Kick-Out-Meeting“ bezeichnet. An dieser Sitzung sollte das gesamte Projekt(kern)team teilnehmen und idealerweise auch ein Vertreter des Lenkungsausschusses. Minimaler Ablauf: • Dank an alle Beteiligten • Die ursprünglichen Ziele werden in einer Abschlusspräsentation mit den

erreichten Zielen verglichen • (Beginn der) Erfahrungssicherung • Formale Entlastung des Projektmanagers und des Projektteams, Auflösung

des Projekts

Anschließend kann der nicht-förmliche Teil erfolgen: • Abschlussparty? • Incentives?

Die Abschlusssitzung



1.83 – 17.09.2012 Seite 149 von 228

PM Basis

Nach DIN 69901-5:2009 /DIN09/ ist der Projektabschlussbericht (engl. project closing report) eine „zusammenfassende, abschließende Darstellung von Aufgaben und erzielten Ergebnissen, von Zeit-, Kosten- und Personalaufwand sowie gegebenenfalls von Hinweisen für mögliche Anschlussprojekte.“

Folgender Aufbau ist möglich: 1. Projektauftrag/Projektziel 2. Planungsunterlagen vor Projektfreigabe 3. Ist-Unterlagen bei Projektende 4. Abschlussanalyse (Gegenüberstellung von ursprünglichen und im

Projektverlauf aktualisierten Plangrößen mit den Ergebnissen bei Projektende) bezüglich a) Terminen, Aufwänden, Kosten und b) inhaltlicher Zielerreichung

5. Dank an alle Beteiligten für deren Mitwirkung 6. Ansprechpartner zur weiteren Betreuung des Projekts

Der Projektabschlussbericht (1/2): Aufbau und Inhalt



1.83 – 17.09.2012 Seite 150 von 228

PM Basis

Der Projektabschlussbericht (2/2): Formular

Der Abschlussbericht umfasst im Allgemeinen nur wenige Seiten. Da er „das Gegenstück“ zum Projektauftrag aus dem Projektstart ist, wird er vom Projektsponsor und vom Projektmanager unterschrieben (grüne Pfeile).


Projekt

Kostenstelle

Projektmanager

4. Projektabnahme

1.1 Zielsetzung des Projekts

3. Nachprojektphase

ToDo

Unterschrift Projektsponsor / Auftraggeber

2. Projektverlauf

1. Projektergebnisse

Verantwortlich Termin

1.2 Zielerreichung, Änderungen

1.3 Wichtige Einzelergebnisse

2.1 Planwerte: Termine

2.4 Istwert: Kosten2.3 Planwert: Kosten

Beginn Einführung Abschluss

2.2 Istwerte: Termine Beginn Einführung Abschluss

Unterschrift Projektmanager

Projekt-Id


1.83 – 17.09.2012 Seite 151 von 228

PM Basis

Während des Projekts, spätestens aber zum Projektende, können oder müssen einzelne Ergebnisse oder erbrachte Leistungen durch den Auftraggeber formal abgenommen werden. Oftmals sind hiermit vertragliche Vereinbarungen und Zahlungen verbunden. Das Abnahmeprotokoll sollte folgende Elemente beinhalten: • Die Beschreibung des abzunehmenden Liefergegenstands • Ggf. erkannte Mängel und Vorbehalte bei der Abnahme • Unterschriften des Auftragnehmers und des Projektmanagers

Nach DIN 69901-5:2009 /DIN09/ ist die Abnahme eine „unternehmerische Entscheidung des Auftraggebers, dass ein (Teil-)Ergebnis den Vereinbarungen und Erwartungen entspricht und somit als Grundlage für nachfolgende Prozesse verwendet werden kann und muss.“

Das Abnahmeprotokoll (1/2): Aufbau und Inhalt



1.83 – 17.09.2012 Seite 152 von 228

PM Basis

/Schreck10/

Das Abnahmeprotokoll (2/2): Formular


Gesamtleistung

Teilleistung wie angegeben

………………………………………………………………

Projekt

Vertrag vom

Projektmanager

Tag und Ort der Abnahme

Unterschrift ProjektmanagerUnterschrift Auftraggeber

Abnahmegegenstand

Auftraggeber vertreten durch

Auftragnehmer vertreten durch

Bei der Abnahme wurde festgestellt

Die Leistung ist mangelfrei

Die Leistung wird mit folgendem Vorbehalt abgenommen

………………………………………………………………

Projekt-Id


1.83 – 17.09.2012 Seite 153 von 228

PM Basis

Frage

Wurden die gesetzten Ziele (Kosten, Umfang, Termine) erreicht?

Sind die Gründe für den Erfolg/Misserfolg bekannt und dokumentiert?

Ist bekannt und dokumentiert, was im Projekt (besonders) gut, was (besonders) schlecht gelaufen ist?

Ist der Kunde/Auftraggeber mit dem Ergebnis zufrieden? (Sonderbefragung)

Ist der Projektabschlussbericht fertig und die Ergebnisse gemäß des PM-Plans abgelegt?

Sind alle notwendigen Abnahmen erfolgt?

Wie war das Klima im Team?(Sonderbefragung)

Sind noch Restarbeiten zu erledigen?

Ja Nein Offen Maßnahmen

Checkliste: Kann das Projekt abgeschlossen werden?




1.83 – 17.09.2012 Seite 154 von 228


1. Das Lernen aus abgeschlossenen Projekten ist ungemein wichtig und sollte daher nicht vernachlässigt werden

2. Das „passende“ Maß an Abschlussdokumenten muss schon zu Beginn des Projekts definiert werden. Ein Zuviel ist ebenso schädlich wie ein Zuwenig

3. Erwähnen Sie neben den positiven auch die negativen Erfahrungen im Projektabschlussbericht

4. Das Loben der Mitarbeiter ist am Ende des Projekts enorm wichtig!



1.83 – 17.09.2012 Seite 155 von 228


1. Warum ist der (formelle) Projektabschluss so wichtig? 2. Muss der Projektabschluss auch bei abgebrochenen

Projekten durchgeführt werden? Warum? 3. Warum ist es oftmals schwierig, einen formellen Abschluss mit

allen Teammitgliedern zu gestalten?



1.83 – 17.09.2012 Seite 156 von 228

PM Basis

Teil III Te

il III

Seite 156-199

Teil III: Teambuilding, Kommunikation, Qualität, Risiko

Kapitel 9 Teambuilding

Kapitel 10 Kommunikation

Kapitel 11 Qualitätsmanagement

Kapitel 12 Risikomanagement


1.83 – 17.09.2012 Seite 157 von 228

PM Basis

Kapitel 9: Teambuilding

Kapi

tel 9

• Arbeitsgruppe oder Team? • Die Teamentwicklungsphasen nach Tuckman (Definition,

Verlauf) • Tipps zum Kapitel • Fragen zum Kapitel

Seite 157-162

Teil III

9. 10. 11. Teambuilding III. 12.


1.83 – 17.09.2012 Seite 158 von 228

PM Basis

Ein Projekt kann nur erfolgreich sein, wenn das Projektteam gute Ergebnisse in der Zusammenarbeit erzielt. Hierzu muss bei der Zusammenstellung des Projektteams (zum Beginn des Projekts) auf eine passende Mischung von Charakteren geachtet werden. Die Begriffe Arbeitsgruppe und Team können folgendermaßen beschrieben werden: • Eine Arbeitsgruppe basiert schwerpunktmäßig auf der Arbeitsleistung seiner

Gruppenmitglieder und wird mehr oder weniger hierarchisch geführt. Die Verantwortung für die Leistung und den Erfolg wird durch den Arbeitsgruppenleiter gesteuert und weniger durch die Gruppe selbst

• Ein Team basiert auf der Summe der einzelnen Leistungen – echte Synergieeffekte treten auf. Die Verantwortung für die Leistung und den Erfolg wird durch die gesamte Gruppe getragen. Es gibt eine effektive Mischung zwischen individueller und Gesamtverantwortung

Zur weiteren Unterscheidung und zur Charakterisierung der Leistungsfähigkeit werden vielfach auch die Begriffe Haufen, Arbeitsgruppe, Pseudo-Team, potenzielles Team, echtes Team und Hochleistungsteam verwendet. Anmerkung: Auch die Teamleistungsentwicklung und die Teamziele müssen geplant und aktiv gestaltet werden.

Arbeitsgruppe oder Team?



1.83 – 17.09.2012 Seite 159 von 228

PM Basis

Bei der Entwicklung eines Teams werden folgende Phasen durchlaufen: 1. Orientierungsphase (Forming): Das Team findet sich zusammen, kennt sich aber

noch nicht; sehr formaler und höflicher Umgang miteinander. Jeder macht das, was er kann

2. Auseinandersetzungsphase (Storming): Die Unklarheiten bei der Umsetzung führen zu Konflikten zwischen den Teammitglieder; diese Konflikte werden mehr oder weniger offen ausgetragen

3. Organisationsphase (Norming): Es bilden und etablieren sich Spielregeln im Umgang miteinander. Ein „Wir-Gefühl“ entsteht und das Team unterstützt sich bei Problemen

4. Arbeitsphase (Performing): Das Team arbeitet ohne Reibungsverluste miteinander und die Projektarbeit steht im Vordergrund

5. Ablösungsphase (Adjourning; alternativ: Super-Performing): Das Team arbeitet ohne Steuerung von außen zusammen und bringt hervorragende Leistungen. Mit dem Projektende wird das Team allerdings aufgelöst

Die Phasen 1-4 wurden 1968 von B. Tuckman beschrieben. Der Projektmanager muss bei allen Phasen aktiv den Teamstatus beeinflussen.

Die Teamentwicklungsphasen nach Tuckman (1/2): Definition



1.83 – 17.09.2012 Seite 160 von 228

PM Basis

Die Teamentwicklungsphasen nach Tuckman (2/2): Verlauf


Projektdauer

Leistungs-fähigkeit

des TeamsForming Storming PerformingNorming

Tal der Tränen

Hügel der Euphorie

Orientierung Machtkampf Stabilisierung Produktion

minimal tolerierbare Leistung


1.83 – 17.09.2012 Seite 161 von 228


• Planen Sie genügend Zeit für die Teamentwicklung ein und gestalten Sie diese aktiv



1.83 – 17.09.2012 Seite 162 von 228


1. Nennen Sie die vier Teamentwicklungsphasen nach Tuckman! 2. Was müssen Sie als Projektmanager in den einzelnen

Phasen (aktiv) tun?



1.83 – 17.09.2012 Seite 163 von 228

PM Basis

Kapitel 10: Kommunikation

Kapi

tel 1

0 • Die Spielregeln der Kommunikation im Projekt • Die Kommunikationsmatrix (Definition, Beispiel) • Die Verantwortlichkeitsmatrix (Definition, Das RACI-Format,

Beispiel im RACI-Format) • Tipps zum Kapitel • Fragen zum Kapitel

Seite 163-171

Teil III

9. 10. 11. Kommunikation III. 12.


1.83 – 17.09.2012 Seite 164 von 228

PM Basis

Die Spielregeln der internen Kommunikation im Team sollten zu Beginn durch das Team festgelegt werden. Spielregeln könnten sein: • Probleme werden offen (und direkt) angesprochen • Konstruktives Feedback ist erwünscht • Jeder trägt zur Erreichung der Teamziele bei • Abweichende Meinungen werden ernstgenommen • Absprachen und Zeiten werden eingehalten • Interkulturelle Unterschiede werden akzeptiert • Stärken und Schwächen (der Teammitglieder) werden akzeptiert Für die Team-Meetings sollte zudem beachtet werden: • Besprechungen werden vorbereitet • Die Beiträge sind kurz und prägnant • Es redet immer nur einer zu gleichen Zeit • Die Ergebnisse werden während des Meetings festgehalten, abgestimmt und

protokolliert

Die Spielregeln der Kommunikation im Projekt



1.83 – 17.09.2012 Seite 165 von 228

PM Basis

Bereits zu Beginn des Projekts sollte festgelegt werden, wer welche Infor-mationen wann und über welches Medium erhält. Hierzu wird die Kommuni-kationsmatrix erstellt, die die einzelnen Adressatengruppen den entsprechen-den Kommunikationsmitteln zuordnet. Die Matrix gibt (zunächst) die Sicht des Projektteams wieder – die gesamte Kommunikation wird über das Projektteam und über den Projektmanager gesteuert.

Typische Medien sind: • Das direkte Gespräch • Der Vortrag / die Präsentation • Die E-Mail • Das Internet oder das Intranet (Projektportal) • Das Kick-Off-Meeting • Der Aushang Eine (einfache) Kommunikationsmatrix ist auf der nächsten Folie dargestellt.

Die Kommunikationsmatrix (1/2): Definition



1.83 – 17.09.2012 Seite 166 von 228

PM Basis

/SchuWi02/

Die Kommunikationsmatrix (2/2): Beispiel


Geschäftsführer

Abteilungsleiter

Gruppenleiter

Mitarbeiter

Betriebsrat

Vertriebspartner

WerWomit

Call Center

Kunden

Freie Mitarbeiter

Gespräch Präsen-tation E-Mail Internet Kick-Off Aushang Projekt-

zeitung

X X X

X X XXX

X

X

X

X

X

X

X X

X

X

X

X

X

X

X X


1.83 – 17.09.2012 Seite 167 von 228

PM Basis

Die Verantwortung für einzelne Teilaufgaben (z.B. Arbeitspakete) wird entweder durch den Projektmanager (in Zusammenarbeit mit dem Lenkungs-ausschuss) oder durch das Projektteam zugeteilt. Mit der Verantwortlich-keitsmatrix (engl. RAM – Responsibility Assignment Matrix) kann dies für alle Aufgaben im Projekt einfach festgehalten werden. Zusätzlich werden auch die Mitarbeits- und die Zustimmungspflichten festgehalten. Nach PMI /PBG08/ kann man hierzu das RACI-Format verwenden.

Die Verantwortlichkeitsmatrix (1/3): Definition



1.83 – 17.09.2012 Seite 168 von 228

PM Basis

Es stehen folgende Möglichkeiten der Beschreibung zur Verfügung: • R = Responsible (verantwortlich): Verantwortlich dafür, dass die Aufgabe

umgesetzt wird • A = Accountable (zuständig): Verantwortlich im kaufmännischen und

juristischen Sinn • C = Consulted (beraten): Derjenige, der die Aufgabe umsetzen muss

(bidirektionale Kommunikation) • I = Informed (informieren): Wird über das Ergebnis/den Fortschritt informiert

(unidirektionale Kommunikation)

Anmerkung: Die Bezeichnungsweisen und auch die Bedeutung der einzelnen Buchstaben variieren in der Literatur sehr stark. Eine Verantwortlichkeitsmatrix im RACI-Format ist auf der nächsten Folie dargestellt.

Die Verantwortlichkeitsmatrix (2/3): Das RACI-Format



1.83 – 17.09.2012 Seite 169 von 228

PM Basis

Die Verantwortlichkeitsmatrix (3/3): Beispiel im RACI-Format


Proj

ektm

anag

er

Auftr

agge

ber

Lenk

ungs

-au

ssch

uss

PTM

1

Personen / Gremien

Aufgaben / Arbeitspakete

Projektmanagementplan erstellen

Fach

abte

ilung

1

Kostenplan aufstellen R

R C

Fachanforderung „Einkauf“ klären

Externe Zeitvorgaben definieren R IA

PTM

2

PTM

3

C I

R C

A

I

I I

Fach

abte

ilung

2

IProjektfeier organisieren R CI IA

A

R = Verantwortung A = Zuständig C = Mitarbeit I = Information


1.83 – 17.09.2012 Seite 170 von 228


• Besprechen Sie die Kommunikationsregeln (innerhalb des Projektteams) und versichern Sie sich, dass diese auch verstanden und akzeptiert werden

• Erstellen Sie frühzeitig die Kommunikationsmatrix und stimmen Sie diese mit den Stakeholdern und dem Projektteam ab



1.83 – 17.09.2012 Seite 171 von 228


1. Wer erstellt die Kommunikationsmatrix? 2. Was ist die RACI-Matrix? Wann kommt sie (sinnvollerweise)

zum Einsatz? 3. Was ist der Unterschied zwischen dem „R“ und dem „A“ in der

RACI-Matrix?



1.83 – 17.09.2012 Seite 172 von 228

PM Basis

Kapitel 11: Qualitätsmanagement

Kapi

tel 1

1 • Das Qualitätsmanagement: Definitionen • Das Qualitätsmanagement in Projekten (Grundsätzliches,

Teilgebiete, Kosten, Wirkung von Prävention) • Der PDCA-Zyklus • Teilgebiete der Qualitätssicherung in Projekten • Liefergegenstände für das Qualitätsmanagement in Projekten • Checkliste (Qualitätsmanagement in Projekten) • Tipps zum Kapitel • Fragen zum Kapitel

Seite 172-184

Teil III

9. 10. 11. Qualitätsmanagement III. 12.


1.83 – 17.09.2012 Seite 173 von 228

PM Basis

• Qualität ist nach ISO 9000 „die Gesamtheit der Funktionen und Merkmale eines Produkts oder einer Dienstleistung, mit denen ausgewiesene oder implizierte Bedürfnisse erfüllt werden können.“

• „Qualitätsmanagement in Projekten ist ein projektbegleitendes Kontroll-verfahren, das die gewünschte Funktionalität, Qualität und termingerechte Fertigstellung eines Produkts und somit also den Projekterfolg gewährleisten soll.“ /PMag/

• Generell steht nach allgemeiner, heutiger Meinung der Kunde (oder der Markt) im Mittelpunkt der Qualitätsbetrachtungen. Wenn die Kundenanforderungen erfüllt werden, so ist die Qualität (des Produkts und damit des Projekts) ausreichend

• Das QM hat sich seit den 50er Jahren weiterentwickelt: Während zunächst nur reine Qualitätskontrollen durchgeführt wurden, kam dann die Qualitätssicherung hinzu. Das Qualitätsmanagement entstand in den 80er Jahren und wurde seit den 90er Jahren zum Total Quality Management (TQM) ausgebaut

• Weitere Begriffe aus dem Qualitätsmanagement: Six Sigma, Kaizen, …

Das Qualitätsmanagement: Definitionen



1.83 – 17.09.2012 Seite 174 von 228

PM Basis

• Qualität ist (indirekter) Bestandteil des magischen Dreiecks des PM • Qualitätsmanagement ist mit einem zusätzlichen administrativen Aufwand

verbunden; die dafür benötigten Ressourcen müssen deshalb im Vorfeld mit geplant und dann im Laufe des Projekts bereitgestellt werden

• Bei vielen produzierenden Unternehmen können Meilensteine in Projekten erst erreicht werden, wenn die entsprechenden Qualitätsdokumente (meistens in Form von Formularen oder Checklisten) ausgefüllt sind

• Qualität ist kein absoluter Begriff, sondern passt sich den Anforderungen an. Wenn im Projekt beispielsweise gefordert wird, dass bestimmte Toleranzen erlaubt sind, so müssen diese erreicht werden (aber eben nur diese). Übererfüllung der geforderten Qualitätskriterien (das sogenannte „Gold Plating“) verbessert die Qualität nicht

• Qualität ist immer Aufgabe des gesamten Projektteams (und auch des Managements)

• Typische Methoden und Tools die in Projekten angewandt werden sind beispielsweise: Fehlermöglichkeit und Einfluss-Analyse (FMEA) und Quality Function Deployment (QFD)

Das Qualitätsmanagement in Projekten (1/4): Grundsätzliches



1.83 – 17.09.2012 Seite 175 von 228

PM Basis

• Nach dem PMI /PBG08/ unterteilt sich das Qualitätsmanagement in die drei Teilbereiche Qualitätsplanung (Planning), Durchführen der Qualitätssicherung (Perform Quality Assurance) und Durchführen der Qualitätslenkung (Perform Quality Control)

• Zur Darstellung der kontinuierlichen Qualitätsverbesserung (CIP – Continuous Process Improvement) wird oft der PDCA-Zyklus (siehe einige Folien später) herangezogen. Dabei wird die Qualitätsverbesserung als fortwährender Kreislauf betrachtet, in dem die vier Phasen Plan (Planen), Do (Ausführen), Check (Prüfen) und Act (Handeln) durchlaufen werden

• Die Qualitätssicherung im Projekt (siehe spätere Folie) betrachtet nicht nur das entstehende Produkt, sondern auch den Projektverlauf. Hierzu gehört neben der Betrachtung der Projektprozesse auch die Teamentwicklung

Das Qualitätsmanagement in Projekten (2/4): Teilgebiete



1.83 – 17.09.2012 Seite 176 von 228

PM Basis

Gesamtqualitäts-kosten

Qualitätsgrad

Kosten der Qualitäts-maßnahmenKosten der Schäden

durch Qualitätsmängel (= Schadensausmaß)

Optimaler Qualitätsgrad

zu wenig Qualitätsmanagement

zu vielQualitätsmanagement

Kosten

Qualitätsmanagement kostet und bringt Nutzen gleichzeitig. Gutes/Optimales Qualitätsmanagement zeichnet sich durch die Balance der Kosten der Qualitätsmaßnahmen und der möglichen Schäden aus.

Das Qualitätsmanagement in Projekten (3/4): Kosten



1.83 – 17.09.2012 Seite 177 von 228

PM Basis

/Jenny09/ /Kerzner08/

Das Qualitätsmanagement in Projekten (4/4): Wirkung von Prävention


0

20

40

100

60

80

Prüfkosten Prüfkosten

PräventionPrävention

Interne Fehler

Interne Fehler

Ein-sparungen

Externe Fehler

Ext. Fehler


1.83 – 17.09.2012 Seite 178 von 228

PM Basis

Der PDCA-Zyklus wird für das Qualitätsmanagement benutzt, findet aber auch in anderen Bereichen Anwendung.

Plan Plane die Maßnahme Do Führe die Maßnahme aus Check Überprüfe die Wirkung /

den Erfolg der Maßnahme Act Integriere die Maßnahme

in den Standardablauf

Der PDCA-Zyklus


Plan

DoCheck

Act


1.83 – 17.09.2012 Seite 179 von 228

PM Basis

nach /Litke05/

Teilgebiete der Qualitätssicherung in Projekten


Qualitäts-sicherung

Konstruktiv-organisatorische

QS

Konstruktive QS

Soziale QS

Analytische QS

• Inspektion• Reviews• Tests

• Prozesse• Vorgehensmodelle• Standards und

Richtlinien

• Teamentwicklung• Zusammenarbeit• Veranstaltungen

• Verfahren• Methoden• Werkzeuge


1.83 – 17.09.2012 Seite 180 von 228

PM Basis

/Jenny09/

Liefergegenstände für das Qualitätsmanagement in Projekten (1/2)


Qualitätskonzept Das Qualitätskonzept definiert den Rahmen des in einem Projekt anzuwendenden Qualitätsmanagements und sichert die organisatorische und instrumentelle Machbarkeit

Qualitätsplan

Prüfplan

Qualitätsbericht

Im Qualitätsplan werden die Qualitätsziele und -aktivitäten der Qualitätssicherung für das konkrete Projekt definiert. Er ist in einem Projekt das zentrale Dokument zur Planung und

Lenkung der definierten Prozess- und Projektqualität

Liefergegenstand Kurzbeschreibung

Der Prüfplan legt den organisatorischen und zeitlichen Ablauf der Prüfungen fest und ergänzt den Projekt- und Qualitätsplan als Handlungsgrundlage

Der Qualitätsbericht fasst die projektbezogenen Berichte wie Prüf- und Testberichte/-protokolle zusammen. Er rapportiert den allgemeinen QS-Status des Projekts und schlägt

allfällige Maßnahmen vor, welche vom Auftraggeber eingeleitet werden sollten


1.83 – 17.09.2012 Seite 181 von 228

PM Basis

/Jenny09/

Liefergegenstände für das Qualitätsmanagement in Projekten (2/2)


Testkonzept

Testplan

Testfall

Testdaten

Testbericht

Dokument, das den Umfang, die Vorgehensweise, die Einsatzmittel und die Zeitplanung der intendierten Tests (inklusive aller Aktivitäten) beschreibt

1. Zeitliche Planung der Testdurchführung (Zuordnung der Testfälle zu Testern und Festlegung des Durchführungszeitpunktes)

2. Verzeichnis aller Testfälle, in der Regel thematisch bzw. nach Testzielen gruppiert

Dokument, das die Testaktivitäten und -ergebnisse zusammenfasst und eine darauf basierende Bewertung der Testobjekte enthält

Eingabe- und Zustandswerte für ein Testobjekt und Sollwerte nach Ausführung des betreffenden Testfalls

Umfasst Angaben zu den für die Ausführung notwendigen Vorbedingungen, zur Menge der Eingabewerte oder Inputs und zur Menge der erwarteten Sollwerte, zu Prüfanweisungen

sowie zu den erwarteten Nachbedingungen

Liefergegenstand Kurzbeschreibung


1.83 – 17.09.2012 Seite 182 von 228

PM Basis

Qualitätsmanagement in Projekten: Checkliste



Existiert ein Qualitäts(management)plan?

Ist eine für das Qualitätsmanagement zuständige Person (= Qualitätsmanger) bestimmt?

Sind Quality Gates (mit entsprechenden Sitzungen und Protokollen) etabliert?

Sind eindeutige Messkriterien für das Passieren der Quality Gates definiert?

Sind Überprüfungen für die Abnahme von Liefergegenständen vorgesehen?

Sind Maßnahmen zur Fehlervermeidung abgestimmt und eingeplant?

Wird die Qualität der Projektdurchführung (regelmäßig) überprüft?

Frage Ja Nein MaßnahmenOffen


1.83 – 17.09.2012 Seite 183 von 228


• Qualitätsmanagement ist eine Führungsaufgabe. Entsprechend muss die Leitungsebene beim QM involviert sein

• Meistens werden Qualitätsmängel durch schlechtes Management oder mangelhafte Prozesse oder Prozessabläufe hervorgerufen, selten jedoch durch die Mitarbeiter



1.83 – 17.09.2012 Seite 184 von 228


1. Was sind die Unterschiede von Qualitäts-, Test- und Prüfplänen?

2. Was ist der PDCA-Zyklus und was sagt er aus? 3. Welche Qualitätssicherungsmethoden kennen Sie?



1.83 – 17.09.2012 Seite 185 von 228

PM Basis

Kapitel 12: Risikomanagement

Kapi

tel 1

2 • Das Risikomanagement (Definitionen, Teilgebiete) • Der Risikobegriff • Die Risikokategorien • Die Risikoidentifizierung • Die Risikoanalyse • Die Risikomatrix (Beschreibung, Darstellung, Eingruppierung,

Übung) • Die Risikobehandlung • Das Risikocontrolling • Tipps zum Kapitel • Fragen zum Kapitel

Seite 185-199

Teil III

9. 10. 11. Risikomanagement III. 12.


1.83 – 17.09.2012 Seite 186 von 228

PM Basis

• Das ProjektMagazin /PMag/ definiert Risikomanagement als „der Teil des Projektmanagements, der sich mit der Identifizierung, Analyse und Beherrschung von Risiken für die geplante Projektabwicklung beschäftigt.“

• In der Wikipedia /Wiki-d/ steht: „Unter Risikomanagement ist die systematische Erfassung und Bewertung von Risiken sowie die Steuerung von Reaktionen auf festgestellte Risiken zu verstehen.“

• Nach Kerzner /Kerzner08/ ist Risikomanagement „die Art oder Praxis, mit Risiko umzugehen …“

Der Begriff „Risikomanagement“ ist nicht eindeutig definiert. Insbesondere die Begriffe des PMIs /PBG08/ weichen vom allgemeinen Sprachgebrauch ab. Achtung: Risikomanagement ist nicht zu verwechseln mit Krisenmanagement, also der Situation, wenn nicht vorhergesehene oder nicht betrachtete Ereignisse das Projekt gefährden.

Das Risikomanagement (1/2): Definitionen



1.83 – 17.09.2012 Seite 187 von 228

PM Basis

Das Risikomanagement (2/2): Teilgebiete


1. Risiko-identifikation

2. Risikoanalyse3. Risikobe-handlung

4. Risiko-kontrolle

a) Vorsorge(Eventualmaßnahmen)

b) Vorbeugung

a) Risikobewertungb) Risikoklassifizierung

0. Risikoplanung


1.83 – 17.09.2012 Seite 188 von 228

PM Basis

„Risiko ist ein in der Zukunft liegendes mögliches Ereignis im Projektverlauf, welches die Gefährdung oder eingeschränkte Erreichung der Projektziele oder das Scheitern des Projekts zur Folge hat. Das Eintreten (Eintrittswahrschein-lichkeit) dieses Ereignisses und/oder die Tragweite ist mit einer Unsicherheit behaftet.“ „Risiko ist ein Maß für die Wahrscheinlichkeit und die Auswirkungen davon, ein Projektziel nicht zu erreichen.“ /Kerzner08/

Ein Risiko setzt sich zusammen aus … • den möglichen Problemen, • der Wahrscheinlichkeit ihres Eintretens, • den Auswirkungen auf das Projekt im Falle des Eintritts und • den Maßnahmen zur Reduzierung des Risikos.

„Risk“ hat im englischen Sprachraum sowohl die Bedeutung von „Bedrohung“ wie auch von „Chance“. Im Deutschen wird meistens der negative Aspekt betrachtet. Spruch: „Ein Projekt ohne Risiko ist kein Projekt!“

Der Risikobegriff



1.83 – 17.09.2012 Seite 189 von 228

PM Basis

Typische Risikokategorien, die betrachtet werden müssen, sind: • Technologische Risiken (z.B. Materialeigenschaften) • Personelle Risiken (Ausfall von Mitarbeitern durch Krankheit oder Urlaub) • Abwicklungstechnische Risiken (Planungen zu ungenau) • Terminrisiken (Planung zu ambitioniert) • Wirtschaftliche Risiken (Bonität des Kunden) • Politische Risiken (Änderung der Geschäftsführungsstrategie) • Wettbewerbs- und Marktrisiken (Konkurrenz früher am Markt, Produkt

preislich nicht marktfähig) • Juristische Risiken (Änderung der Gesetzeslage) • Risiken aus Umwelteinflüssen (Wetter) • …

Diese Einteilung kann beliebig ergänzt oder anders vorgenommen werden.

Die Risikokategorien



1.83 – 17.09.2012 Seite 190 von 228

PM Basis

• Bei der Risikoidentifizierung werden die Risiken ermittelt, d.h. benannt und gelistet, unabhängig davon, ob ihr Auftreten wahrscheinlich ist oder eine große Auswirkung auf das Projekt hat

• Typischerweise wird die Risikoidentifizierung vom Projektmanager in Zusammenarbeit mit Mitgliedern des Managements oder des Projektteams in einer Risikoklausur durchgeführt; die Risikoklausur sollte in einer sehr frühen Projekt(vor)phase stattfinden

• Für die Risikoidentifizierung sollten die Projektziele und ggf. schon die Projektpläne (in einer ersten Fassung) vorliegen

• Hilfreich sind vorgefertigte Listen mit Risiken aus alten, abgeschlossenen Projekten; diese umfassen oftmals einige hundert Risiken

• Etwa 80-90 % der Risiken liegen in den frühen Phasen eines Projekts. Die Auswirkungen sind aber meistens erst in den späten Phasen erkennbar

• Die Ergebnisse der Risikoidentifizierung sollten unbedingt schriftlich fixiert werden (im sogenannten Risikoregister)

Die Risikoidentifizierung



1.83 – 17.09.2012 Seite 191 von 228

PM Basis

• In der Risikoanalyse werden die identifizierten Risiken qualitativ und quantitativ bewertet

• Die notwendigen Informationen für die Risikoanalyse können aus verschie-denen Quellen kommen, so z.B. aus dem Vergleich mit bereits abge-schlossenen Projekten (Lessons Learned) oder ähnlichen Systemen, aus Expertenbefragungen, aus der Analyse der vorhandenen Unterlagen, …

• Die qualitative Bewertung basiert auf subjektiven Einschätzungen und liefert die Eintrittswahrscheinlichkeit und die Auswirkungen auf das Projekt

• Bei der quantitativen Bewertung werden für alle Risiken die Kosten ermittelt; die so entstehende Vergleichbarkeit gilt als objektiv. Dieser aufwendige Ansatz ist insbesondere im amerikanischen Raum verbreitet

• Als Ergebnisse der (qualitativen) Risikoanalyse wird oftmals die Risikomatrix erstellt (siehe nächste Folien)

Die Risikoanalyse



1.83 – 17.09.2012 Seite 192 von 228

PM Basis

• In der Risikomatrix werden die einzelnen identifizierten und analysierten Risiken eingetragen. Die Abschätzungen für die Eintrittswahrscheinlichkeit und die Auswirkung (in Bezug auf Kosten, Termin und Qualität) auf das Projekt bilden die Basis

• Hierzu wird eine xy-Darstellung gewählt, bei der die x-Achse die (Tragweite der) Auswirkungen auf das Projekt und die y-Achse die Eintrittswahrscheinlichkeit beschreibt (siehe nachfolgende Grafik)

• Dann werden die Risiken (meistens als Kreise mit der entsprechenden Risikonummer) eingetragen; in der nachfolgenden Grafik als Risikonummern 1 bis 4

• Ist (bei Projektstart) auch nur ein Risiko im „roten Bereich“, so sollte das Projekt nicht begonnen werden

• In der grafischen Darstellung sollten nicht mehr als 5-10 Risiken eingetragen werden

• Die Risikomatrix wird während des Projekts beobachtet und gesteuert – sie taucht auch in den Managementberichten auf

Die Risikomatrix (1/4): Beschreibung



1.83 – 17.09.2012 Seite 193 von 228

PM Basis

Auswirkung auf das Projekt

Eint

ritts

wah

rsch

einl

ichk

eit

hoch

hochniedrig

niedrig

5

4

3

2

1

5431 2

1

3

4 2

Die Risikomatrix (2/4): Darstellung



1.83 – 17.09.2012 Seite 194 von 228

PM Basis

Generell besteht die Schwierigkeit, die Risiken nach ihrer Eintrittswahrschein-lichkeit einzuordnen („Was ist hoch und was ist niedrig“?). Hierbei helfen Skalen, die die Wahrscheinlichkeiten auf Punkte übertragen. Solche Skalen sollten vor Projektstart (im Risikomanagementplan) vorliegen, um ein abgestimmtes Bild zu erhalten.

Die Risikomatrix (3/4): Eingruppierung


niedrig hochmittel

5 % 99 %90 %80 %70 %60 %20 %10 % 50 %45 %40 %30 %

1 2 3 4 5

eher hocheher niedrig


1.83 – 17.09.2012 Seite 195 von 228

PM Basis

Erstellen Sie ein Risikoregister und eine Risikomatrix für Ihr Projekt.

Dauer: 45 Min.

Die Risikomatrix (4/4): Übung




1.83 – 17.09.2012 Seite 196 von 228

PM Basis

Zur Risikobehandlung gibt es folgende Antwortstrategien:

Die Risikobehandlung

Anmerkung: Risikoakzeptanz darf nicht mit Risikoignoranz verwechselt werden!


Risikostrategie Beispiele

1. Risikovermeidung (Avoid): Die Gefahr des Auftretens durch Ursachenbehandlung

verbannen

3. Risikominderung (Mitigate): Reduktion der Wahrscheinlichkeit des Eintritts oder der

Auswirkung

4. Risikoakzeptanz (Accept): Mit dem Risiko leben

• Risikobehaftetes Arbeitspaket oder Mitarbeiter aus dem Projekt entfernen

2. Risikoübertragung (Transfer): Übergabe des Risikos an eine andere Partei

• Versichern eines Transports• Verlagern von Tätigkeiten an Fremdfirmen

• Erstellung eines Prototypen• Schulung von Mitarbeitern

• Mitteilung an das Management, dass Mehrkosten auftreten


1.83 – 17.09.2012 Seite 197 von 228

PM Basis

Das Risikocontrolling umfasst folgende Aufgaben: • Kontinuierliche Erfassung und Überwachung aller relevanten Risiken • Regelmäßige Berichterstattung über die wesentlichen Risiken an die

jeweiligen Entscheidungsträger • Aufzeigen von Abweichungen gegenüber den vorgegebenen

risikopolitischen Zielen • Einleiten von Maßnahmen zur Erreichung der angestrebten risikopolitischen

Ziele • Laufende Überprüfung der risikoorientierten Steuerungsmaßnahmen und

ggf. Anpassung an veränderte Bedingungen

Das Risikocontrolling



1.83 – 17.09.2012 Seite 198 von 228


• Planen Sie (reichlich) Zeit für das Risikomanagement ein – und binden Sie, falls möglich, die Stakeholder mit ein

• Vermeiden Sie die Betrachtung von „Trivial-Risiken“, die immer in Projekten auftreten können, wie beispielsweise „zu wenig Ressourcen“

• Versuchen Sie, die Risiken monetär zu bewerten



1.83 – 17.09.2012 Seite 199 von 228


1. Wann sollten Sie mit dem Risikomanagement starten? 2. Was kann bei mangelhaften Risikomanagement passieren? 3. Was ist die Risikomatrix? 4. Wie viele Risiken treten „typischerweise“ im Projekt auf? 5. Welche Risikobehandlungsstrategien kennen Sie?



1.83 – 17.09.2012 Seite 200 von 228

PM Basis

Teil IV Te

il IV

Seite 200-228

Teil IV: Anhang

Anhang A Literatur, Weblinks, Sprüche und Glossar Anhang B Normen, Verbände und Zertifikate Anhang C PM in der SW-Entwicklung, Reifegradmodelle Anhang D Weitere Präsentationen, Kontakt zum Autor


1.83 – 17.09.2012 Seite 201 von 228

PM Basis

Anhang A: Literatur, Weblinks, Sprüche und Glossar

Anha

ng A

• Literatur • Literatur für Softwareprojekte • Weblinks • Sprüche • Glossar – Top-Ten-Begriffe

Seite 201-214

Anmerkung: Die Literaturstellen und Weblinks, die ein fettgedruckte Kürzel aufweisen, werden oftmals als Referenz in dieser Präsentation genutzt!

Teil IV

A. B. C. Literatur, Weblinks, Sprüche und Glossar IV. D.


1.83 – 17.09.2012 Seite 202 von 228

PM Basis Literatur (1/4)

/Andler11/ Nicolai Andler: Tools für Projektmanagement, Workshops und Consulting: Kompendium der wichtigsten Techniken und Methoden, Publicis Corporate Publishing, Erlangen 4. Auflage 2011, ISBN 978-3-89578-398-2

/Burghardt12/ Manfred Burghardt: Projektmanagement. Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten, Publicis Corporate Publishing, Erlangen 9. Auflage 2012, ISBN 978-3-89578-399-9

/DeMarco98/ Tom de Marco: Der Termin. Ein Roman über Projektmanagement, Hanser, München 1998, ISBN 978-3-446-40165-5

/DIN09/ Deutsche Gesellschaft für Projektmanagement: DIN-NORMEN IM PROJEKTMANAGE-MENT. DIN-Taschenbuch 472, Beuth-Verlag, 2009, ISBN 978-3-410-17818-7

/Drews10/ Günter Drews, Norbert Hillebrandt: Lexikon der Projektmanagement-Methoden, Haufe, München 2. Auflage 2010, ISBN 978-3-448-10224-6

/Duden11/ Duden Verlag (Hrsg.): Projektmanagement, Bibliographisches Institut, Mannheim 2011, ISBN 978-3-411-74511-1

/Fiedler09/ Rudolf Fiedler: Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle, Vieweg + Teubner, Wiesbaden 5. Auflage 2009, ISBN 978-3-8348-0889-9



1.83 – 17.09.2012 Seite 203 von 228


/GPM12/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 5. Auflage 2012, ISBN 978-3-924841-40-9

/Hemmrich11/ Angela Hemmrich, Horst Harrant: Projektmanagement. In 7 Schritten zum Erfolg, Hanser Wirtschaft, München 3. Auflage 2011, ISBN 978-3-446-42567-5

/Hab12/ Gerhard Hab, Reinhard Wagner: Projektmanagement in der Automobilindustrie: Effizientes Management von Fahrzeugprojekten entlang der Wertschöpfungskette, Gabler, Wiesbaden 4. Auflage 2012, ISBN 978-3-834-94368-2

/Jenny09/ Bruno Jenny: Projektmanagement. Das Wissen für den Profi, Vdf Hochschulverlag, Zürich 2. Auflage 2009, ISBN 978-3-7281-3290-1

/Kerzner08/ Harold Kerzner: Projektmanagement – Ein systemorientierter Ansatz zur Planung und Steuerung, mitp-Verlag, Bonn 2. Auflage 2008, ISBN 978-3-8266-1666-2

/Kerzner09/ Harold Kerzner: Project Management. A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, Hoboken, New Jersey 10th Edition 2009, ISBN 978-0-470-27870-3

/Kerzner13/ Harold Kerzner: Project Management. A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, Hoboken, New Jersey 11th Edition 2013, ISBN 978-1-1180-2227-6

/Lessel12/ Wolfgang Lessel: Pocket Business. Projektmanagement: Projekte effizient planen – Projekte erfolgreich umsetzen, Bibliographisches Institut, Mannheim 4. Auflage 2012, ISBN 978-3-411-86999-2



1.83 – 17.09.2012 Seite 204 von 228


/Litke05/ Hans-Dieter Litke: Projektmanagement für die Praxis, Hanser, München 2005, ISBN 978-3-446-22907-5

/Litke07/ Hans-Dieter Litke: Projektmanagement: Methoden, Techniken, Verhaltensweisen. Evolutionäres Projektmanagement, Hanser, München 5. Auflage 2007, ISBN 978-3-446-40997-2

/Litke12/ Hans-Dieter Litke, Ilonka Kunov, Heinz Schulz-Wimmer: Projektmanagement, Haufe, München 2. Auflage 2012, ISBN 978-3-648-03502-3

/OGC09/ OGC: Managing Successful Projects with PRINCE2. Edition 2009, The Stationery Office Ltd 2009, ISBN 978-0-11-331059-3

/Patzak08/ Gerold Patzak, Günter Rattay: Projektmanagement, Linde, Wien 5. Auflage 2008, ISBN 978-3-7143-0149-6

/PBG08/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fourth Edition 2008, ISBN 978-1-933890-51-7

/PBG08-d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). Vierte Ausgabe, Project Management Institute, Philadelphia, Pennsylvania 2008, ISBN 978-1-933890-66-1

/PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9



1.83 – 17.09.2012 Seite 205 von 228


/PM-Fach11/ RKW (Hrsg.): Projektmanagement-Fachmann, Wissenschaft & Praxis, Sternenfels 10. Auflage 2011, ISBN 978-3-89673-575-1

/Reiter03/ Wilfried Reiter: Die nackte Wahrheit über Projektmanagement, Orell Füssli Verlag, Zürich 2003, ISBN 978-3-280-05018-7

/Schelle08/ Heinz Schelle, Roland Ottmann, Astrid Pfeiffer: Projektmanager, GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 3. Auflage 2008, ISBN 978-3-9248-4126-3

/Schelle10/ Heinz Schelle: Projekte zum Erfolg führen. Projektmanagement systematisch und kom-pakt, Deutscher Taschenbuch Verlag, München 6. Auflage 2010, ISBN 978-3-423-05888-9

/Schels07/ Ignatz Schels: Projektmanagement mit Excel 2007, Addison-Wesley, München 2007, ISBN 978-3-8273-2600-3

/Schreck10/ Berta C. Schreckeneder: Projektcontrolling, Haufe, München 3. Auflage 2010, ISBN 978-3-448-10097-6

/SchuWi02/ Heinz Schulz-Wimmer: Projekte managen, Haufe, München 2002, ISBN 978-3-448-04786-8

/Schwarze10/ Jochen Schwarze: Projektmanagement mit Netzplantechnik, Nwb, Bochum 10. Auflage 2010, ISBN 978-3-482-56060-6

/Tumusch07/ Klaus D. Tumuscheit: Überleben im Projekt – 10 Projektfallen und wie man sie umgeht, Redline Wirtschaft bei Verlag Moderne Industrie, München 3. Auflage 2007, ISBN 978-3-478-81296-2



1.83 – 17.09.2012 Seite 206 von 228

PM Basis Literatur für Softwareprojekte

/Balzert08/ Helmut Balzert: Lehrbuch der Softwaretechnik: Band 2 – Softwaremanagement, Spektrum Akademischer Verlag, Heidelberg 2. Auflage 2008, ISBN 978-3-8274-1161-7

/Berkun09/ Scott Berkun: Die Kunst des IT-Projektmanagements, O'Reilly, Köln 2. Auflage 2009, ISBN 978-3-89721-921-2

/Kitz04/ Andreas Kitz: IT-Projektmanagement, Galileo Press, Bonn 2004, ISBN 978-3-89842-396-0 /Mangold08/ Pascal Mangold: IT-Projektmanagement kompakt, Spektrum Akademischer Verlag,

Heidelberg, Berlin 3. Auflage 2008, ISBN 978-3-8274-1937-8 /Spitczok10/ Niklas Spitczok von Brisinski, Guy Vollmer: Pragmatisches IT-Projektmanagement.

Softwareentwicklungsprojekte auf Basis des PMI PMBOK Guide führen, dpunkt, Heidelberg 2010, ISBN 978-3-89864-651-2

/Streitz04/ Siegfried Streitz: IT-Projekte retten – Risiken beherrschen und Schieflagen beseitigen, Hanser, München 2004, ISBN 978-3-446-22627-2

/Tiemeyer08/ Ernst Tiemeyer: IT-Projekte erfolgreich managen, Rauscher Verlag, Haag 2008, ISBN 978-3-940045-01-0

/Tiemeyer10/ Ernst Tiemeyer: Handbuch IT-Projektmanagement: Vorgehensmodelle, Managementinstrumente, Good Practices, Hanser, München 2010, ISBN 978-3-446-42192-9

/Wie10/ Hans W. Wieczorrek, Peter Mertens: Management von IT-Projekten, Springer, Heidelberg 4. Auflage 2010, ISBN 978-3-642-16126-1



1.83 – 17.09.2012 Seite 207 von 228

PM Basis

Auf den folgenden Seiten sind Weblinks aufgeführt, die zur Beschreibung oder zur Einarbeitung in das Projektmanagement hilfreich sein können. Auf diese Weblinks wird zum Teil in dieser Präsentation verwiesen. Eine Bewertung der Websites und deren Inhalte wird hier nicht vorgenommen, kann aber vom Autor abgefragt werden. Dabei wurden die Weblinks folgendermaßen eingeteilt: • Nachschlagewerke • Freie Ressourcen • PM-Organisationen und Verbände • (Freie) PM-Tools

Legende für die nachfolgenden Folien – so werden die Weblinks klassifiziert: / / Verweis auf Website generell /*/ Verweis auf eine Website, die als Buch-Ergänzung dient /#/ Verweis auf einzelnes Thema auf einer Website /#V/ Verweis auf ein Video (auf einer Website) mit Minutenangabe und Sprache

Weblinks (1/5): Erläuterungen



1.83 – 17.09.2012 Seite 208 von 228

PM Basis

Weblinks (2/5): Nachschlagewerke

/OLEV/ Online-Verwaltungslexikon: http://www.olev.de; eingesehen am 06.07.2012 /PBlog/ Weiterer deutschsprachiger PM-Blog: http://pm-blog.com; eingesehen am

01.06.2011 /PMag/ Deutschsprachiges Online-Magazin zum Projektmanagement – das

ProjektMagazin (kostenpflichtig): http://www.projektmagazin.de; eingesehen am 06.07.2012

/Wiki-d/ Deutsche Wikipedia: https://de.wikipedia.org; eingesehen am 01.06.2011 /Wiki-e/ Englische Wikipedia: https://en.wikipedia.org; eingesehen am 01.06.2011 /#Wiki-PM/ Projektmanagement in der deutschen Wikipedia:

https://de.wikipedia.org/wiki/Projektmanagement; eingesehen am 01.06.2011 /#Wiki-K-PM/ Kategorie Projektmanagement in der deutschen Wikipedia:

https://de.wikipedia.org/wiki/Kategorie:Projektmanagement; eingesehen am 01.06.2011

/#Wiki-Links-PM/ Linkliste zum Projektmanagement in der deutschen Wikipedia: https://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Projektmanagement/Linkliste; eingesehen am 01.06.2011


http://www.olev.de/

https://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Projektmanagement/Linkliste

http://pm-blog.com/


http://de.wikipedia.org/wiki/Projektmanagement

https://de.wikipedia.org/

http://de.wikipedia.org/wiki/Kategorie:Projektmanagement

http://en.wikipedia.org/


1.83 – 17.09.2012 Seite 209 von 228

PM Basis

Weblinks (3/5): Freie Ressourcen

/PM-Atlas/ Projektmanagement-Atlas (dt./engl./andere) als DINA1 oder DIN2-Poster – stellt Gesamtzusammenhänge im Projektmanagement dar: http://www.project-roadmap.com/project-portal/; eingesehen am 31.05.2013

/PM-Hand/ Unterlagen zum PM (dt.): http://www.pm-handbuch.com; eingesehen am 01.06.2011

/PM-Glossar/ Glossar nach PMI-Standard (dt.): http://projektmanagement-definitionen.de; eingesehen am 01.06.2011


http://www.project-roadmap.com/project-portal/

http://www.pm-handbuch.com/

http://www.project-roadmap.com/project-portal/

http://projektmanagement-definitionen.de/

http://projektmanagement-definitionen.de/


1.83 – 17.09.2012 Seite 210 von 228

PM Basis

Weblinks (4/5): PM-Organisationen und Verbände

/GPM-IPMA/ Deutsche Gesellschaft für Projektmanagement: http://www.gpm-ipma.de; eingesehen am 01.06.2011

/PMI/ Project Management Institute (PMI): http://www.pmi.org; eingesehen am 01.06.2011

/PMI-MUC/ Project Management Institute – Munich Chapter: http://www.pmi-muc.de; eingesehen am 01.06.2011

/PRINCE2-d/ PRINCE2-Forum (dt.): http://www.prince2-deutschland.de; eingesehen am 01.06.2011


http://www.pmi-muc.de/

http://www.prince2-deutschland.de/

http://www.gpm-ipma.de/

http://www.pmi.org/


1.83 – 17.09.2012 Seite 211 von 228

PM Basis

Weblinks (5/5): (Freie) PM-Tools

/in-STEP/ Tool-Hersteller microTOOL – in-STEP BLUE: http://www.microtool.de; eingesehen am 01.06.2011

/Openproj/ Open-Source-PM-Tool: http://www.openproj.org; eingesehen am 01.06.2011


http://www.microtool.de/

http://www.openproj.org/


1.83 – 17.09.2012 Seite 212 von 228

PM Basis Sprüche

„Wir wissen, warum Projekte scheitern, wir wissen, wie wir das verhindern können – warum scheitern Projekte trotzdem?“ (unbekannt)

„Qualität ist, wenn der Kunde wiederkommt und nicht das Produkt.“ (unbekannt) „Ein gutes Projekt beherrscht die Änderungen und wird nicht von ihnen beherrscht.“

(unbekannt) „Die Aufgabe von Projektmanagement sollte nicht das Behandeln, sondern das

Vermeiden von Problemen sein.“ (unbekannt) „Projektmanagement kostet Geld, kein Projektmanagement kostet noch mehr Geld!“

(unbekannt) „Lieferbarkeit ist auch eine Funktion.“ (unbekannt) „Projektmanagement ist die Kunst, mit 10 Fingern 11 Korken gleichzeitig unter Wasser

zu halten.“ (unbekannt) „Managen Sie Projekte, indem Sie ihre Risiken managen.“ (Tom DeMarco, Der Termin,

Hanser 1997) „Management is loss of control.“ „Adding manpower to a late software project makes it later.“ (“Brooks Law”) „Der Projektmanager ist Unternehmer auf Zeit im Unternehmen.“ (unbekannt)



1.83 – 17.09.2012 Seite 213 von 228

PM Basis

Begriff Beschreibung Quelle

Arbeitspaket (engl. Work Package)

Eine in sich geschlossene Aufgabenstellung innerhalb eines Projekts, die bis zu einem festgelegten Zeitpunkt mit definiertem Ergebnis und Aufwand vollbracht werden kann

/DIN09/

Kick-Off-Meeting Eine Veranstaltung zum Projektstart nach Unterzeichnung des Projektauftrags, an dem sich der Projektmanager mit dem Projekt(kern)team trifft. Es werden die Projektziele erläutert und ein allgemeines Verständnis von Projektinhalt und Projektrahmenbedingungen hergestellt

selbst

Liefergegenstand (engl. Deliverable)

Ein eindeutiges oder überprüfbares Produkt oder Ergebnis oder eine Dienstleistung, das/die hergestellt oder erbracht werden muss, um einen Prozess, eine Phase oder ein Projekt abschließen zu können

/PBG08-d/

Projektauftrag (engl. Project Charter)

Ein Dokument, das vom Initiator oder Sponsor des Projekts herausgegeben wird, der die Existenz des Projekts formell genehmigt, und das den Projektmanager berechtigt, Ressourcen der Organisation für Projektvorgänge einzusetzen

/PBG08-d/

Glossar – Top-Ten-Begriffe (1/2)



1.83 – 17.09.2012 Seite 214 von 228

PM Basis

Begriff Beschreibung Quelle Projekthandbuch (engl. project manual)

Ein Dokument, welches „alle notwendigen“ organisatorischen Vorgaben und Rahmenbedingungen des Projekts enthält.

selbst

Projektmanager (engl. project manager)

Die von der Trägerorganisation für die Erreichung der Projektziele bestimmte Person.

/PBG08-d/

Projektmanagement (engl. project management)

Das Anwenden von Wissen, Fähigkeiten und Methoden auf Vorgänge des Projekts, damit die Anforderungen des Projekts erfüllt werden.

/DIN09/

Projektmanagementplan (engl. project management plan)

Ein formelles genehmigtes Dokument, in dem definiert ist, wie das Projekt ausgeführt, überwacht und gesteuert wird.

/PBG08-d/

Projektstrukturplan, PSP (engl. Work Breakdown Structure, WBS)

Der Projektstrukturplan unterteilt das Projekt in einzelne, hierarchische Teilpakete, die ausgeführt werden können, um die Projektziele zu erreichen.

selbst

Projektabschlussbericht (engl. project closing report)

Eine zusammenfassende, abschließende Darstellung von Aufgaben und erzielten Ergebnissen, von Zeit-, Kosten- und Personalaufwand sowie gegebenenfalls von Hinweisen für mögliche Anschlussprojekte.

/DIN09/

Glossar – Top-Ten-Begriffe (2/2)



1.83 – 17.09.2012 Seite 215 von 228

PM Basis

Anhang B: Normen, Verbände und Zertifikate

Anha

ng B

• DIN-Normen – Neue Fassung • DIN-Normen – Alte Fassung • ISO 21500 – Im September 2012 erschienen

Seite 215-218

Teil IV

A. B. C. Normen, Verbände und Zertifikate IV. D.


1.83 – 17.09.2012 Seite 216 von 228

PM Basis DIN-Normen – Neue Fassung

Die ab Januar 2009 gültige Norm „DIN 69901: Projektmanagement – Projektmanagementsysteme“ /DIN09/ gliedert sich in die Teile 1 bis 5 und ersetzt die bisherige Normenreihe DIN 69901 bis 69905; in der Norm „DIN 69900: Projektmanagement – Netzplantechnik; Beschreibungen und Begriffe“ wurden die Teile 1 und 2 der alten DIN 69900 zusammengefasst und aktualisiert. • DIN Norm 69 900 Projektmanagement – Netzplantechnik: Beschreibungen

und Begriffe • DIN Norm 69 901-1 Projektmanagement: Grundlagen • DIN Norm 69 901-2 Projektmanagement: Prozesse, Prozessmodell • DIN Norm 69 901-3 Projektmanagement: Methoden • DIN Norm 69 901-4 Projektmanagement: Daten und Datenmodell • DIN Norm 69 901-5 Projektmanagement: Begriffe Zum Thema Zertifizierungen & Normen gibt es eine eigenständige Präsentation des Autors, die ebenfalls auf der Website unter https://www.peterjohann-consulting.de/_pdf/peco-pm-zertifizierungen.pdf frei verfügbar ist.


https://www.peterjohann-consulting.de/_pdf/peco-pm-zertifizierungen.pdf

https://www.peterjohann-consulting.de/_pdf/peco-pm-zertifizierungen.pdf


1.83 – 17.09.2012 Seite 217 von 228

PM Basis

Diese Normengruppe wurde Anfang 2009 durch die neue Normengruppe abgelöst. Da sie aber in der Literatur noch oft zitiert wird, ist sie hier noch aufgeführt. In Klammern ist das Datum der letzten Überarbeitung angegeben. • DIN Norm 69 900-1 Netzplantechnik: Begriffe (August 1987) • DIN Norm 69 900-2 Netzplantechnik: Darstellungstechnik (August 1987) • DIN Norm 69 901 Projektmanagement: Begriffe (August 1987) • DIN Norm 69 902 Einsatzmittel: Begriffe (August 1987) • DIN Norm 69 903 Kosten und Leistung, Finanzmittel: Begriffe (August

1987) • DIN Norm 69 904 Projektmanagementsysteme: Elemente und Strukturen

(November 2000) • DIN Norm 69 905 Projektabwicklung: Begriffe (Mai 1997)

DIN-Normen – Alte Fassung



1.83 – 17.09.2012 Seite 218 von 228

PM Basis

ISO 21500 – Im September 2012 erschienen


Im Herbst 2007 startete die ISO (International Standardization Organization) ein Normungsprojekt für die Norm ISO 21500 „A Guidance on Project Management“, die im September 2012 veröffentlicht wurde. Im Wesentlichen basiert die ISO 21500:2012 auf den Ansätzen der DIN 69901-2:2009-01, dem PMBOK Guide sowie der Norm ISO 10006 „Quality manage-ment systems – Guidelines for quality management in projects.“ /PMag/ Die ISO 21500:2012 fungiert als ein so genannter „Umbrella Standard“. Das bedeutet, dass die Norm nicht im Konflikt zu bestehenden nationalen Normen steht und ein übergreifendes, einheitliches Verständnis von Projekt-management schafft, auf das sich die anderen Normen beziehen können. Die ISO 21500 umfasst 38 Seiten, definiert 16 Begriffe, 10 Themengebiete und 5 Prozessgruppen. Ein Prozessmodell ist das zentrale Element der Norm. Hierin werden recht grob 39 Projektmanagementprozesse beschrieben, nicht jedoch die benötigten Methoden.

Detaillierung in der „Zertifizierungen & Normen“-Präsentation des Autors.


1.83 – 17.09.2012 Seite 219 von 228

PM Basis

Anhang C: PM in der SW-Entwicklung, Reifegradmodelle

Anha

ng C

• Besonderheiten • Organisationsformen • Weitere Rollen • Das Capability Maturity Model

Seite 219-225

Teil IV

A. B. C. PM in der SW-Entwicklung, Reifegradmodelle IV. D.


1.83 – 17.09.2012 Seite 220 von 228

PM Basis

• Viele weitere Spezialrollen im Projekt • Meistens recht komplexe Systeme • Bei Individualsoftware: Fast immer einhergehend mit Organisations-

veränderungen im Unternehmen – oftmals hoher Widerstand einzelner Fachabteilungen

• Nochmals viele, eigene Vorgehensmodelle für die Softwareerstellung und Softwareentwicklung selbst (V-Modell, Wasserfall, RUP, Agile Ansätze, …)

• Viele SW-Vorgehensmodelle sind iterativ: Damit greifen viele Vorstellungen aus der reinen PM-Welt nicht

• Begriffe wie Grob- und Feinspezifikationen sind in der PM-Welt nahezu unbekannt, in der IT-Welt jedoch essentiell

• Lasten- und Pflichtenheft haben eine andere Bedeutung als in der PM-Welt • Der Produktgedanke ist ein anderer (als bei den meisten Produkten), da

Software auch nach Auslieferung vergleichsweise einfach verändert werden kann

PM in der SW-Entwicklung: Besonderheiten



1.83 – 17.09.2012 Seite 221 von 228

PM Basis

PM in der SW-Entwicklung: Organisation



Projektmanager QS-Verantwortlicher

SW-Architekt

GUI-Verantwortlicher

Projektcontroller

Release-manager Testmanager

Entwickler

Tool-Verantwortlicher

Dokumentations-verantwortlicher


1.83 – 17.09.2012 Seite 222 von 228

PM Basis

• Project Owner: Der Project Owner oder Project Sponsor ist Mitglied des Managements und trägt die Gesamtverantwortung für das Projekt (im Unternehmen). Wird oftmals nicht gewollt, da sehr undankbare Rolle

• Application Owner: Er hat die fachliche (und auch zum Teil kaufmän-nische) Verantwortung für „seine Applikation“, da sie die Arbeitsprozesse seiner Fachabteilung berühren. Ist typischerweise ein Mitglied der Linienführung (Abteilungsleiter)

• Key User: Er ist derjenige, der die Fachvorgaben für die Applikation machen darf und kommt daher typischerweise aus der Fachabteilung des Application Owners. Hat entsprechend einen „übergeordneten“ Blick

• Power User: Er ist derjenige, der die Applikation am häufigsten nutzt und daher seine speziellen Anforderungen und Anmerkungen mitteilen muss

• Medien-Designer: Ist für das optische Erscheinungsbild der Applikationen verantwortlich. Arbeitet daher eng mit dem GUI-Beauftragten zusammen

• Datenbank-Designer: Er ist für die Repräsentation der Dateninhalte in den entsprechenden Datentabellen verantwortlich

PM in der SW-Entwicklung: Weitere Rollen



1.83 – 17.09.2012 Seite 223 von 228

PM Basis

• Das Capability Maturity Model (CMM) definiert den „Reifegrad“ von Organisationen bei der Erstellung von Softwaresystemen

• Der Reifegrad sollte mindestens „Repeatable“, besser aber „Defined“ sein • Ziel sollte es sein, die nächsthöhere Stufe zu erreichen • CMM ist als allgemeine PM-Norm in das CMMI (Capability Maturity Model

Integration) übergegangen oder spezifisch in das CMMI-SW

Das Capability Maturity Model (1/3)



1.83 – 17.09.2012 Seite 224 von 228

PM Basis

Level 1 (Initial): Der SW-Entwicklungsprozess ist gekennzeichnet als „ad hoc“ und häufig chaotisch. Wenige Aufgaben sind definiert. Der persönliche Einsatz einzelner Entwickler ist für den Erfolg hauptverantwortlich.

Level 2 (Repeatable): Grundlegende Projektmanagement-Prozesse hinsichtlich Kosten-, Zeit- und Funktionsplanung sind festgelegt. Abläufe werden nachvollziehbar, auf Erfahrungen kann zurückgegriffen werden.

Level 3 (Defined): Abläufe für Management, Entwicklung und Engineering sind dokumentiert, standardisiert und integriert. Es gibt Standards für die Organisation der Entwicklung und Wartung. Die Schritte sind genau beschrieben.

Level 4 (Managed): Abläufe werden kontrolliert. Es kann steuernd von zentraler Stelle eingegriffen werden, da die Entwicklung transparent ist und gut dokumentiert wird.

Level 5 (Optimized): Erfahrungen werden wiederverwendet. Dazu werden diese von zentraler Stelle mit neuen Ideen verbunden und das resultierende Ergebnis durchgesetzt. Es wird der Ablauf analysiert, um Schwachstellen zu finden, die dann auch ausgemerzt werden können.




1.83 – 17.09.2012 Seite 225 von 228

PM Basis

Anmerkungen: • Level 2 kommt in der Praxis recht häufig vor, Level 3 sollte das Mindest-Ziel sein • Level 5 wird im Allgemeinen weder erreicht noch ist dies wünschenswert



Level 2„Repeatable“

Level 5„Optimized“

Level 4„Managed“

Level 3„Defined“

• Unternehmensweite Prozessorientierung

• Unternehmensweite Prozessdefinition

• Training/Schulung• Software

Management integriert

• Produkt Engineering• Koordination über

Gruppengrenzen• Rezensionen

• Management der Anforderungen

• Software Projekt Management

• Management von Unter– Auftragnehmern

• Qualitätssicherung• Konfigurations-

Management

• Qualitäts-Management

• Erweitertes Prozess-Management

• Problemerkennung und Verhinderung

• Reaktion auf neue Technologien und deren Integration

• Änderungen der Abläufe bei Bedarf


1.83 – 17.09.2012 Seite 226 von 228

PM Basis

Anhang D: Weitere Präsentationen, Kontakt zum Autor

Anha

ng D

• Weitere öffentliche Präsentationen des Autors • Kontakt zum Autor

Seite 226-228

Teil IV

A. B. C. Weitere Präsentationen, Kontakt zum Autor IV. D.


1.83 – 17.09.2012 Seite 227 von 228

PM Basis Weitere öffentliche Präsentationen des Autors

Zu meinen drei Kerndiszi-plinen Projektmanagement, Business Process Management und Require-ments Engineering gibt es jeweils Einführungs-präsentationen, die einen Einstieg in das Themen-gebiet ermöglichen. Diese sollten zunächst gelesen werden, bevor man weitere Präsentation anschaut. Die Ausarbeitungen zum agilen Vorgehen („Agilität & Scrum“) sind unabhängig von den klassischen Präsen-tationen les- und einsetzbar.

Projektmanagement–

Eine Einführung(PM-Basispräsentation)

Business Process Management

–Eine Einführung

(BPM-Basispräsentation)

Requirements Engineering

–Eine Einführung

(RE-Basispräsentation)

Requirements Eingineering:

Spezifikationen–

Eine Anleitung

1 2

1 Lesereihenfolge; Präsentationen mit kleiner Nummer sollten zunächst gelesen werden

direkte Abhängigkeiten

indirekte Abhängigkeiten

lose Abhängigkeiten

Projekt-management

1

2

2

Agilität & Scrum

1



1.83 – 17.09.2012 Seite 228 von 228

PM Basis

Telefon: 0 54 85 / 830 17 29 Mobil: 0 162 / 977 47 65 E-Mail: [email protected] Website: https://www.peterjohann-consulting.de

Sie benötigen noch weitere Informationen? Kontaktieren Sie mich! Peterjohann Consulting Dipl.-Inform. Horst Peterjohann Kattenvenner Straße 24 49549 Ladbergen

Kontakt zum Autor


mailto:[email protected]


https://www.peterjohann-consulting.de/




PECO-PM-Basispräsentation, (C) Peterjohann … · Peterjohann Consulting Projektmanagement:...

Documents

Transcript of PECO-PM-Basispräsentation, (C) Peterjohann … · Peterjohann Consulting Projektmanagement:...