Methoden des Projektmanagements im Vergleich

Transkript

1 Methoden des Projektmanagements im Vergleich PRINCE2 und PMBOK Hochschule Bremen Fakultät 4, Master KSS Dirk Tamke (314050) Teil PRINCE2 Patrick Rehder (199379) Teil PMBOK

2 1 : Inhaltsverzeichnis Inhaltsverzeichnis 1 Inhaltsverzeichnis Einleitung PRINCE Was ist PRINCE2? Struktur von PRINCE Zertifikate (PRINCE2) Fazit PMBOK Einführung Rahmen Prozesse Wissensgebiete Qualifizierungsmodell Fazit Vergleich Abbildungsverzeichnis Quellenverzeichnis PRINCE PMBOK Dirk Tamke, Patrick Rehder 1/34

3 2 : Einleitung Einleitung Das Projektmanagement kann folgendermaßen definiert werden: Projektmanagement wird als Managementaufgabe gegliedert in Projektdefinition, Projektdurchführung und Projektabschluss. Ziel ist, dass Projekte richtig geplant und gesteuert werden, dass die Risiken begrenzt, Chancen genutzt und Projektziele qualitativ, termingerecht und im Kostenrahmen erreicht werden. 1 Die Problemstruktur die im Projektmanagement auftritt kann mit dem sogenannten magischen Dreieck dargestellt werden. Dieses soll ausdrücken, dass die drei Zeile (Sach-, Kosten- und Zeitziel) nicht getrennt voneinander betrachtet werden können. Die Abbildung 1 - Magisches Dreieck des Projektmanagements verdeutlicht diese Zusammenhänge. Verändert sich eine Größe, so hat das Auswirkungen auf die anderen Ziele. Für den Projekterfolg müssen alle drei Ziele vorher festgelegt werden; bei Entscheidungen müssen alle drei Ziele berücksichtigt werden. Abbildung 1 - Magisches Dreieck des Projektmanagements 2 Die verschiedenen Projektmanagement-Methoden können nicht den erfolgreichen Abschluss eines Projektes garantieren, aber sie können durch systematisches Vorbereiten sowie Planen verhindern das ein Projekt an Organisationsmängeln scheitert. Im Folgenden werden zwei Standards des Projektmanagements vorgestellt: PRINCE2 und PMBOK. 1 Quelle: [1-1] 2 Quelle: [1-2] Dirk Tamke, Patrick Rehder 2/34

4 3 : PRINCE PRINCE2 3.1 Was ist PRINCE2? PRINCE2 steht für PRojects IN Controlled Environments Version 2. Es handelt sich hierbei um eine Prozess basierende Methode für das Projektmanagement. 1 PRINCE2 ist Eigentum der britischen Regierung und erschien Die Überarbeitung und Weiterentwicklung von PRINCE2 erfolgt durch die OGC (Office of Government Commerce). Die letzte Überarbeitung durch das OGC erfolgte im Jahr In Abbildung 2: Änderungen bei PRINCE2 im Jahr 2009 werden die wesentlichen Änderungen im Jahr 2009 zu dem Jahr 2005 dargestellt. Diese belaufen sich z.b. auf die Einführung von sieben Grundsätzen, von sieben Themen sowie von sieben Prozessen. Weiterhin existieren in PRINCE2 zwei Techniken, 27 Management-Produkte sowie vier Management- Ebenen (mit Unternehmens- oder Programm-Management, dem Lenkungsausschuss, dem Projektmanager und dem Teammanger). In dieser Ausarbeitung wird nur auf diese neueste Variante aus dem Jahre 2009 eingegangen. Der Schwerpunkt liegt dabei auf den sieben Grundprinzipien, den sieben Themen sowie den sieben Prozessen. Abbildung 2 - Änderungen bei PRINCE2 im Jahr PRINCE2 ist international anerkannt und wird im privaten wie in behördlichen Bereich eingesetzt. Das Besondere an PRINCE2 ist, dass es eine Methode ist die während der gesamten Projektlaufzeit fest- 1 Quelle: [2-1] 2 Quelle: Dirk Tamke, Patrick Rehder 3/34

5 3 : PRINCE legt was zu tun ist, von wem und wann (lenken und managen des Projektes). Aus diesen Grund lässt sich PRINCE2 sehr gut mit verschiedenen Methoden der Produktherstellung kombinieren. 1 Hierfür werden in der Praxis bewährte Verfahren eingesetzt. PRINCE2 ist eine in sich geschlossene und vollständige Methode bei dem zu jedem Zeitpunkt bekannt ist wer die Verantwortung hat. 1 Quelle: [2-2] Dirk Tamke, Patrick Rehder 4/34

6 3 : PRINCE Struktur von PRINCE2 Der Aufbau von PRINCE2 ist in vier Bausteinen (siehe Abbildung 3: PRINCE2 Struktur) aufgeteilt 1 : 1. Sieben Grundprinzipien (Prinziples) 2. Sieben Themen (Themes) 3. Sieben Prozesse (Prozesses) 4. Anpassen von PRINCE2 an die Projektumgebung (Tailoring PRINCE2 to the Project Environment) Abbildung 3 - PRINCE2 Struktur Sieben Grundprinzipien von PRINCE2 Diese Grundprinzipien sind die Grundlage von PRINCE2. Sie werden nicht angepasst an die verschiedenen Projekte und die Anwendung dieser Grundsätze entscheiden letztlich darüber ob bei einem Projekt tatsächlich PRINCE2 angewandt wird. Bei diesen sieben Grundprinzipien von PRINCE2 handelt es sich um folgende: 3 1. Fortlaufende Ausrichtung an den geschäftlichen Anforderungen Es existiert ein Business Case über die gesamte Projektlaufzeit. Das Projekt liefert einen bestimmten Nutzen. Entfällt dieser Nutzen, so wird das Projekt beendet. 2. Lernen aus der Erfahrung Bei PRINCE2 wird ein Erfahrungskatalog geführt, dieser dient dazu zu verhindern dass derselbe Fehler mehrmals gemacht wird. 1 Quelle: [2-3] 2 Quelle: [2-3] 3 Quelle: [2-4] Dirk Tamke, Patrick Rehder 5/34

7 3 : PRINCE Definierte Rollen und Verantwortlichkeiten In einem Projekt existieren drei primäre Interessen. Diese drei primären Interessen werden durch folgende Rollen dargestellt: Unternehmensinteresse Der Unternehmer investiert in ein Projekt um einen bestimmten Nutzen zu erzielen. Benutzerinteresse Diese Sicht spiegelt den Anwender wieder. Er muss später mit den Projektergebnis bzw. Produkt arbeiten. Lieferanteninteresse Mitglieder dieser Rolle erstellen das Projektergebnis und sind für die Qualität verantwortlich. 4. Steuern über Phasen PRINCE2 kennt einen Phasenplan. Bei einem Übergang von einer Phase in den nächsten entscheidet der Lenkungsausschuss ob in dieses Projekt weiter investiert werden soll. Es gibt ein Minimum von zwei Phasen: Die Projektinitiierung und mindestens eine weitere. 5. Managen nach dem Ausnahmeprinzip Für die Ziele in den Projekt werden gewisse Toleranzen definiert (Management by Exception). Zeichnet sich ab das diese Toleranzen über- bzw. unterschritten werden, so muss an die nächst höhere Managementebene berichtet werden. PRINCE2 kennt sechs Toleranzarten: Zeit Kosten Produktqualität Umfang Risiken Nutzen 6. Fokus auf Produkte Ein Projekt nach PRINCE2 fokussiert sich auf die Definition und Auslieferung von Produkten (Ergebnisse), unter besonderer Beachtung der Qualität. 7. Anpassung an die jeweilige Projektsituation PRINCE2 wird für jede Projektsituation angepasst. Diese Anpassung wird von den Projekt- Manager in Verbindung mit dem Lenkungsausschuss vorgenommen. Das Ergebnis wird in einer Projektdokumentation festgehalten. Das Projektteam konzentriert sich dabei auf folgende Bereiche: 1 Anpassung der Themen (durch Strategien und Steuerelemente). Übernahme bestimmter Termini/Sprachregelungen. Überprüfung der Produktbeschreibungen für das Management von Produkten. Überprüfung der Beschreibungen der PRINCE2-Projektrollen. Anpassung der Prozesse an die oben aufgezählten Gesichtspunkte. 1 Quelle: [2-5] Dirk Tamke, Patrick Rehder 6/34

8 3 : PRINCE Sieben Themen von PRINCE Hier werden Bereiche des Projektmanagements geschrieben, welche während des Projektes kontinuierlich behandelt werden. Jeder Projektmanager muss diese Themen beachten, damit die Prozesse effektiv sind. 1 Zu den sieben Grundprinzipien von PRINCE2 gehören die folgenden sieben Themen: 2, 3 1. Business Case Das Projekt muss über eine betriebswirtschaftliche Rechtfertigung verfügen. Existiert keine solche Berechtigung, dann wird das Projekt nicht gestartet, bzw. entfällt diese Berechtigung während der Projektlaufzeit, dann wird das Projekt eingestellt. Beantwortet die Frage: Warum?. 2. Organization Definiert und etabliert die verschiedenen Rollen bzw. Verantwortlichkeiten. Dazugehören beispielsweise der Lenkungsausschuss (Project Board Das können sein genau ein Auftraggeber, Benutzervertreter sowie Lieferantenvertreter) und das Projektmanagement. Das Projektmanagement plant, es delegiert, überwacht und steuert. Der Lenkungsauschuss ist verantwortlich für die Ressourcen, für das Budget. Beantwortet die Frage: Wer?. 3. Quality Hier werden die Verfahren festgelegt mit denen das Projekt die Produkte überprüfen wird. Beantwortet die Frage: Was?. 4. Plans Pläne müssen vom Lenkungssauschuss genehmigt werden. Bei PRINCE2 werden drei verschiedene Ebenen von Plänen unterschieden: Projektpläne Phasenpläne Teampläne (nicht immer vorhanden) Beantwortet die Frage: Wo? Von Wem? Wann? Wie viel?. 5. Risk Bei dem Risikomanagement sollen die Unsicherheiten (die Chancen sowie evtl. Bedrohungen) identifiziert, bewertet und kontrolliert werden. Dadurch soll die Erfolgswahrscheinlichkeit des Projektes steigen. 1 Quelle: [2-3] 2 Quelle: [2-6] 3 Quelle: [2-5] Dirk Tamke, Patrick Rehder 7/34

9 3 : PRINCE Beantwortet die Frage: Was wäre wenn?. 6. Change Dieses Thema behandelt offene Punkte bzw. potentielle Änderungen die entsprechende Auswirkungen auf das Projekt haben können. Sie werden identifiziert, bewertet und kontrolliert. Beantwortet die Frage: Nur dann, wenn...?. 7. Progress Das Thema ist die Überwachung und die Kontrolle der Ergebnisse. Hier wird z. B.: festgestellt ob ein Projekt weiter geführt werden soll. Beantwortet die Frage: Wo sind wir jetzt? Wohin gehen wir? Sollen wir fortfahren? Sieben Prozesse von PRINCE2 Um ein Projekt durchzuführen gehören zu PRINCE2 sieben Prozesse aufgeteilt. Dieser Teilung liegen die verschiedenen Phasen innerhalb eines Projektes zugrunde. 1 Bei der PRINCE2 Version aus dem Jahre 2005 betrug die Anzahl der Prozesse, einschließlich eines Planning-Prozesses (PL) noch Acht. 2 Diese sieben Prozesse sind zusätzlich in kleinere Unterprozesse aufgeteilt. 3 Die Abbildung 4 - PRINCE2 Prozesse (Seite 11) zeigt die sieben Prozesse in Bezug auf die verschiedenen Management Ebenen (Lenken - Directing, Managen - Managing, Liefern - Delivering). Bei den sieben Prozessen handelt es sich um folgende: 1. Starting up a Project (SU) Vorbereiten eines Projektes Es wird ein Business Case erstellt, die Vorgehensweise im Projekt skizziert. Dieser Prozess dient dazu, von einer Projektidee zu einer Projektbeschreibung zu gelangen. Der Lenkungsausschuss wird festgelegt. Es existieren folgende Unterprozesse: Auftraggeber und Projektmanager ernennen Vorhandene Erfahrung erfassen Projektmanagementteam entwerfen und ernennen Business Case erstellen Projektlösungsansatz auswählen und Projektbeschreibung zusammenstellen Initiierungsphase planen 2. Initiating a Project (IP) - Initiieren eines Projekts Hier werden die Projektmanagementprozesse etabliert. inklusive Projektleitdokument (Projektinitiierungsdokument) Für diesen Prozess gibt es weitere acht Unterprozesse: 1 Quelle: [2-7] 2 Quelle: [2-8] 3 Quelle: [2-9] Dirk Tamke, Patrick Rehder 8/34

10 3 : PRINCE Risikomanagementstrategie erstellen Konfigurationsmanagementstrategie erstellen Qualitätsmanagementstrategie erstellen Konfigurationsmanagementstrategie erstellen Projektsteuerungsmittel einrichten Projektplan erstellen Business Case verfeinern Projektleitdokumentation zusammenstellen 3. Directing a Project (DP) - Lenken eines Projekts Der Lenkungsausschuss billigt bei den Phasengrenzen den Übertritt in eine neue Phase. Nach dem Grundprinzip Managen nach dem Ausnahmeprinzip (siehe Kapitel Sieben Grundprinzipien von PRINCE2, Seite 5) greift der Lenkungsauschuss innerhalb eine Phase nur ein, wenn der Toleranzbereich voraussichtlich überschritten wird. Dem Prozess sind folgende Unterprozesse zugeordnet: Initiierung freigeben Projekt freigeben Phasen- oder Ausnahmeplan freigeben Ad-hoc-Anweisungen geben Projektabschluss freigeben 4. Controlling a Stage (CS) - Steuern einer Phase Dieser Prozess handelt von der täglichen Arbeit des Projektmanagers. Die Fortschritte werden den Lenkungsausschuss gemeldet. Die Unterprozesse sind hier folgende: Arbeitspaket freigeben Status eines Arbeitspakets prüfen Abgeschlossene Arbeitspakete entgegennehmen Phasenstatus prüfen Über Projektstatus berichten Offene Punkte und Risiken erfassen und untersuchen Offene Punkte und Risiken eskalieren Korrekturmaßnahme einleiten 5. Managing Product Delivery (MP) - Managen der Produktlieferung Hier erfolgt die Trennung zwischen den Projektmanagement und der fachlichen Projektarbeit. Die Unterprozesse sind: Arbeitspaket annehmen Arbeitspaket ausführen Arbeitspaket abliefern Dirk Tamke, Patrick Rehder 9/34

11 3 : PRINCE Managing Stage Boundaries (SB) - Managen der Phasenübergänge Hier werden die Aktivitäten für den Übergang von einer Phase in die nächste Phase beschrieben. Dem Prozess sind folgende Unterprozesse zugeordnet: Nächste Phase planen Projektplan aktualisieren Business Case aktualisieren Über Phasenabschluss berichten Ausnahmeplan erstellen 7. Closing a Project (CP) - Abschließen eines Projekts Hier wird sichergestellt, dass der Abschluss eines Projektes ebenso wie der Start und die Durchführung eines Projektes in einer kontrollierten Art und Weise stattfindet. Hierfür gehört z.b: die Abnahme des Kunden, die Übergabe der Projektdokumente sowie die Erstellung des Projektabschlussberichtes. Für die letzte Phase existieren diese Unterprozesse: Planmäßigen Abschluss vorbereiten Vorzeitigen Abschluss vorbereiten Produkte übergeben Projekt bewerten Projektabschluss empfehlen Dirk Tamke, Patrick Rehder 10/34

12 3 : PRINCE Abbildung 4 - PRINCE2 Prozesse Anpassen von PRINCE2 an die Projektumgebung PRINCE2 kann an verschiedene Projektumgebungen angepasst werden. Dabei ist es unerheblich um welche Größenordnung (klein, mittel, groß) bzw. um welche Art von Projekt (IT-Projekt, Elektroindustrie,...) es sich handelt. Es gilt allerdings zu beachten, dass die sieben Grundprinzipien von PRINCE2 nicht angepasst werden. Sie dienen gewissermaßen als Richtlinie. Angepasst auf spezielle Projektbedürfnisse können z.b.: die Themen, die Rollen (besonders bei kleinen Projekten ist es oft sinnvoll das eine Person verschiedene Rollen im Managementteam übernimmt. Zu beachten gilt allerdings das mindestens drei Rollen existieren müssen: Kunde, Lieferantenvertreter, Projektmanager) oder auch die Prozesse. Bei den Prozessen könnten z.b.: die beiden Prozesse Starting up a Project (SU) und Initiating a Project (IP) zusammengelegt werden. 1 Quelle: Dirk Tamke, Patrick Rehder 11/34

13 3 : PRINCE Zertifikate (PRINCE2) Die Ausbildung im Bereich PRINCE2 erfolgt in zwei Stufen. Der Foundation-Prüfung und der Practitioner-Prüfung. 1 In Deutschland existieren verschiedene Organisationen die eine Schulung, offizielles Prüfungsmaterial sowie eine anschließende Prüfung anbieten. Sämtliche Anbieter müssen von der Office of Government Commerce akkreditiert sein. In Deutschland zählen hierzu z.b.: HEITCON3 MASTERS Consulting Bundestechnologiezentrum für Elektro- und Informationstechnik e.v. in Oldenburg Weltweit gibt es mehr als PRINCE2 Practitioner und die Prüfungen zu den PRINCE2 Zertifikaten können in mehr als 56 Länder abgelegt werden. Es werden mehr als Prüfungen zum Practitioner pro Woche abgenommen. 2 Anhand dieser Zahlen kann man also von einem erfolgreichen Foundation Bei der Foundation-Prüfung handelt es sich um einen Grundlagentest. Das Ziel ist dem Mitarbeiter das Wissen zu vermitteln um sich in einem Projektumfeld mit PRINCE2 als Projektmitarbeiter zu bewegen. 3 Für das Belegen dieser Prüfung sind keine Voraussetzungen notwendig. Es werden Projektbegriffe geklärt, das Magische Dreieck behandelt, Unterschiede von PRINCE2 zu weiteren Projekt- Managementmethoden erläutert. Darüber hinaus werden die Prozesse von PRINCE2 gelehrt. 4 Die Dauer eines solchen Seminares ist 2-3 Tage und die eigentliche Prüfung ist ein Multiple-Choice- Test. Die Kosten eines solchen Zertifikates belaufen sich auf ca ,- Euro Practitioner Die Dauer eines solchen Seminares ist ebenfalls 2-3 Tage und die eigentliche Prüfung auch ein Multiple-Choice-Test. Das Ziel dieser Prüfung ist den Mitarbeiter in die Lage zu versetzen ein Projekt mittels PRINCE2 als Projektleiter bzw. als Teilprojektleiter durchzuführen. 5 1 Quelle: [2-1] 2 Quelle: [2-10] 3 Quelle: [2-11] 4 Quelle: [2-12] 5 Quelle: [2-13] Dirk Tamke, Patrick Rehder 12/34

14 3 : PRINCE Der Inhalt dieses Seminares sind im Wesentlichen Praxisübungen, Risikomanagement, Qualität in der Projektumgebung sowie Konfigurationssteuerung. 1 Die Kosten eines solchen Zertifikates belaufen sich wie bei der Foundation Prüfung auf ca ,- Euro. Im Gegensatz zu dem Foundation-Level muss der Practitioner nach spätestens fünf Jahren verlängert werden (Re-Registration). 2 In Kapitel: 2 Was ist PRINCE2? wird beschreiben das eine ständige Überarbeitung von PRINCE2 erfolgt. Mit der Re-Registration wird gewährleistet, dass sich das Wissen der Besitzer eines solchen Zertifikats immer auf den aktuellsten Stand befindet. Die Kosten für eine Prüfung für die Re-Registration belaufen sich auf etwa 200,- Euro. 1 Quelle: [2-12] 2 Quelle: [2-14] Dirk Tamke, Patrick Rehder 13/34

15 3 : PRINCE Fazit Die Vorteile von PRINCE2 liegen darin, dass diese Methode eine kontrollierte Nutzung von Menschen und Mitteln liefert. Darüber hinaus PRINCE2 gehört zu den best Practise (in der Praxis bewährte Methoden bzw. Vorgehensweisen) in den Unternehmen. 1 PRINCE2 ist durch seine Methode und Prozesse sicherlich als Einstieg in das Projektmanagement sehr gut geeignet. Weitere Vorteile sind: 2, 3 Sie kann auf die Bedürfnisse einzelner Organisationen oder Projekte angepasst werden. Eignet sich für jede Art von Projekt. Bei PRINCE2 gibt es einen kontrollierten Start, eine kontrollierte Mitte sowie ein kontrolliertes Ende. PRINCE2 kann sehr gut mit verschiedenen Methoden der Produktherstellung kombiniert werden. International anerkannt und wird seit Jahren im privaten wie in behördlichen Bereich erfolgreich eingesetzt. Prozesse, Rollen und Dokumente können bei kleineren Projekten zusammengelegt werden. Die Methode ist prozessorientiert und auf eine geschäftliche Rechtfertigung aus der stehenden Organisation ausgerichtet; Es ist eine definierte Organisationsstruktur für das Projektmanagementteam vorhanden. Es existiert ein Business Case der das Projekt rechtfertig und den Nutzen beschreibt. PRINCE2 wird gesteuert über Abnahmekriterien, welche die Qualität sicherstellen. Zu den Nachteilen von PRINCE2 gehört z.b.: 4 PINO (engl.: Prince In Name Only ): Man bedient sich unbedacht der Methodologie, hält sich dabei aber nicht an die Grundsätze. Projektbürokratie durch die starke Ausrichtung auf Dokumente (Project Brief (erstellt im Prozess: Starting up a Project ), Projektleitdokumentation, Projektstatusbericht,...). Ohne Anpassung für kleine Projekte zu schwergewichtig. Unzureichende Berücksichtigung iterativer und agiler Ansätze. Keine Anforderungsanalyse. Nicht Kostenfrei. Die Zertifikate müssen erworben werden und die Literatur direkt vom OGC ist teuer. 1 Quelle: [2-15] 2 Quelle: [2-15] 3 Quelle: [2-8] 4 Quelle: [2-8] Dirk Tamke, Patrick Rehder 14/34

16 4 : PMBOK PMBOK 4.1 Einführung Der Project Management Body of Knowledge ist im PMBOK Guide 1 beschrieben. Die Inhalte wurden von Projektmanagern in der Praxis als geeignete Vorgehensweise ( good practice ) bei der Durchführung von Projekten identifiziert. Es handelt sich bei PMBOK um einen vom American National Standards Institute (ANSI) anerkannten und Project Management Institute (PMI) gepflegten Standard. Nach der ersten Veröffentlichung im Jahr 1987 befindet sich PMBOK mittlerweile in der vierten Version (2008) und umfasst etwa 450 Seiten. Da PMBOK aus Amerika stammt wurden für das Kapitel 4 überwiegend englischsprachige Quellen verwendet. Um eine bessere Zuordnung zum Standard zu ermöglichen wurde auf unnötiges Übersetzen verzichtet. Der PMBOK Guide gliedert sich in 3 Sektionen: Rahmen (The Project Management Framework) Prozesse (Project Management Processes) Wissensgebiete (The Project Management Knowledge Areas) Die einzelnen Sektionen werden im Folgenden erläutert. Zuvor aber noch ein paar Worte zum Urheber von PMBOK, dem Project Management Institute Project Management Institute (PMI) Das Project Management Institute ist eine der weltweit größten, nicht gewinnorientierten Mitgliedervereinigungen, im Hinblick auf Projektmanagement die Größte. Laut eigener Website 2 gehören ihr mehr als Mitglieder und Zertifikatsinhabern in über 185 Ländern an. Das Buch PMP for Dummies spricht von mehr als Mitgliedern (Stand: September 2011) 3. Das Project Management Institute zeichnet sich durch folgende Leistungen aus 2 : Zertifizierungen Definition von weltweiten Standards Unterhalt von länderspezifische Chapters und Communities Seminare Forschung Das deutsche Chapter Project Management Institute Munich Chapter e.v. wurde 1998 gegründet. Es ist vorwiegend in Süddeutschland aktiv und unterhält derzeit Standorte in München, Stuttgart/Karlsruhe, Regensburg/Passau und Nürnberg. 4 1 Verweis: [3-1] 2 Quelle: [3-5] 3 Quelle: [3-2], Seite 9 4 Quelle: [3-6] Dirk Tamke, Patrick Rehder 15/34

17 4 : PMBOK Rahmen Der Rahmen beschreibt den grundsätzlichen Charakter von Projekten bzw. Projektmanagement und teilt sich in zwei Abschnitte. Im ersten Abschnitt werden Grundlagen geklärt: Was ist ein Projekt? Ein Projekt ist das temporäre Bestreben ein einzigartiges Produkt, einen einzigartigen Service oder ein einzigartiges Ergebnis zu entwickeln. Die temporäre Eigenschaft wird durch einen festen Start- und Endzeitpunkt definiert. Außerdem endet ein Projekt, wenn das Ziel nicht mehr erreichbar oder das Resultat nicht mehr von Nutzen ist. 1 Was ist Projektmanagement? Unter Projekt Management ist die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken zur Durchführung von Aktivitäten zur Erreichung der Projektanforderungen zu verstehen. 2 Hierbei müssen die Anforderungen, Wünsche und Erwartungen (Abbildung 5) der Stakeholder identifiziert und berücksichtigt werden. Umfang Risiken Qualität Resourcen Zeit Kosten Abbildung 5 Erwartungen an ein Projekt laut PMBOK Die bei PMBOK genannten Begriffe stellen ein detailliertes magisches Dreieck dar. 3 1 Quelle: [3-1], Seite 5 2 Quelle: [3-1], Seite 6 3 Verweis: Dirk Tamke, Patrick Rehder 16/34

18 4 : PMBOK Es wird auch aufgezeigt wie sich Projekte in einen größeren Kontext einordnen lassen: In Abbildung 6 wird dargestellt wie Projekte zu Programmen zusammengefasst und wiederum in ein oder mehreren Portfolios gebündelt werden können. Wenn ein Unternehmen beispielsweise als Strom- und Wasserversorger tätig ist können alle Projekte der Stromsparte in einem Programm und alle Projekte der Wassersparte in einem anderen Programm zusammengefasst werden. Allgemeine Projekte würden direkt dem Portfolio zugeordnet werden. Portfolio Programm Projekt Projekt Programm Projekt Projekt Projekt Projekt Projekt Projekt Projekt Abbildung 6 Organisation von Projekten in einem größeren Kontext Wo analog beim Projekt vom Projektmanagement gesprochen wird, wird bei Programmen vom Programmmanagement und beim Portfolio vom Portfoliomanagement gesprochen. Die Unterteilung dient zur klaren Trennung der unterschiedlichen Perspektiven. Des Weiteren werden die Rolle des Projektmanagers und das Project Management Office (PMO) erläutert. Dies soll an dieser Stelle jedoch nicht weiter vertieft werden. Dirk Tamke, Patrick Rehder 17/34

19 4 : PMBOK Der zweite Teil des Rahmens beschäftigt sich mit dem Lebenszyklus eines Projekts, Stakeholdern, möglichen Organisationsstrukturen im Unternehmen und Assets. Beim Projektlebenszyklus ist es besonders interessant, dass alle Projekte unabhängig von ihrer Größe und Komplexität in die folgenden Phasen eingeteilt werden können 1 : Starten des Projekts Organisation und Vorbereitung Ausführung der Projektarbeit Beenden des Projekts Diese Unterteilung wird später, bei den Prozessen, wieder aufgegriffen. (Kapitel 4.3, Seite 21) Eine wichtige Tatsache in diesem Zusammenhang ist, dass die Kosten für Änderungen mit dem Voranschreiten des Projekts steigen und die Flexibilität der Stakeholder bei Entscheidungen abnimmt. Die folgende Abbildung 7 illustriert dies: Abbildung 7 Zusammenhang zwischen Kosten, Flexibilität der Stakeholder und Zeit im Projekt 2 Als Stakeholder (Intresseneigner) werden die folgenden Personengruppen genannt 3 : customers/users (Kunden/Benutzer) sponsors (Geldgeber) portfolio managers/portfolio review board program managers project management office project managers project team functional managers (z.b. Beschaffung, Personalabteilung, ) 1 Quelle: [3-1], Seite 16 2 Quelle: [3-1], Seite 17, Abbildung Quelle: [3-1], Seite 25 ff. Dirk Tamke, Patrick Rehder 18/34

20 4 : PMBOK operations management (z.b. Forschung, Test, ) sellers/business partners (z.b. Vertriebspartner, Zulieferer, ) Die einzelnen Stakeholder werden im PMBOK noch näher erläutert, darauf soll an dieser Stelle verzichtet werden. Bei den Organisationsstrukturen für Projekte werden Möglichkeiten genannt wie Projektteams in klassische Unternehmensstrukturen (Stablinienorganisation) integriert werden können. Hierbei wird grundsätzlich zwischen einer funktionalen und einer projektorientierten Sicht unterschieden, wobei es mit der Matrixorganisation Mischformen unterschiedlichen Grades gibt. Abbildung 8 und Abbildung 9 dienen zur Illustration der beiden Extreme: Abbildung 8 funktionalorientierte Organisation 1 Abbildung 9 projektorientierte Organisation 2 1 Quelle: [3-1], Seite 29, Abbildung Quelle: [3-1], Seite 31, Abbildung 2-11 Dirk Tamke, Patrick Rehder 19/34

21 4 : PMBOK Außerdem wird noch auf die unternehmerischen Assets (Vermögenswert) eingegangen, welche in zwei Kategorien eingeteilt werden: Die erste Kategorie enthält Arbeitsrichtlinien (processes and procedures for conducting work) wie zum Beispiel Checklisten, Datenschutzrichtlinien, Vorlagen, Arbeitsanweisungen und Akzepttanzkriterien. Die zweite Kategorie meint die gemeinsame Wissensbasis (corporate knowledge base) des Unternehmens, diese enthält beispielsweise Finanzdaten, historische Informationen, Issues (Probleme) und Projektdaten. Damit ist die Erläuterung zu Assets für Prozesse bei weitem nicht so granular wie bei ITILv3. Dirk Tamke, Patrick Rehder 20/34

22 4 : PMBOK Prozesse Die zweite Sektion im PMBOK besteht aus einem Kapitel welches sich ausschließlich um Prozesse kümmert. Prozesse spielen eine zentrale Rolle bei PMBOK (wie auch bei ITIL), da die Durchführung eines Projekts als Netz aus untereinander verknüpften Prozessen verstanden wird. Eine wichtige Anmerkung im PMBOK ist, dass nicht alle Prozesse starr für alle Projekte angewendet werden können. Der Projektmanager hat in Zusammenarbeit mit dem Projektteam die richtigen Prozesse für jedes Projekt ausfindig zu machen und diese dann passend auszuführen. Alle projektspezifischen Prozesse werden in zwei Hauptkategorien unterteilt: Projektmanagementprozesse produktorientierte Prozesse Erstere erfahren bei PMBOK eine ausführliche Behandlung, da sie dazu dienen ein Projekt zu planen und zu steuern. Letztere hingegen beschreiben Prozesse zur Erschaffung von Produkten, wie beispielsweise das Programmieren einer Klasse. Im Folgenden wird ausschließlich über Projektmanagementprozesse berichtet, da die produktorientierten Prozesse im PMBOK keine weitere Erläuterung erfahren. Die Projektmanagementprozesse werden weiterhin in fünf Gruppen (Project Management Process Groups) eingeteilt: Initiating Planning Executing Monitoring and Controlling Closing Die Gruppen orientieren sich hierbei an den Phasen des Projektlebenszyklus. Initiating Process Group Planning Process Group Executing Process Group Monitoring and Controlling Process Group In Abbildung 10 wird die Interaktion zwischen den Prozessgruppen vereinfacht dargestellt. Dies soll zeigen, dass sich die einzelnen Prozesse nicht auf ihre Gruppe beschränken, sondern ein reger Austausch von Ergebnissen stattfindet. Closing Process Group Abbildung 10 vereinfachte Darstellung der Interaktion zwischen Prozesskategorien 1 1 Quelle: [3-1], Seite 42, Abbildung 3-3 (stark vereinfacht übernommen) Dirk Tamke, Patrick Rehder 21/34

23 4 : PMBOK PMBOK beschreibt 42 Projektmanagementprozesse welche in Kapitel 3 vom PMBOK Guide durch einen Namen, eine kurze Beschreibung und Ein- bzw. Ausgangsinformationen charakterisiert werden. Im Folgenden eine Auflistung: Initiating Process Group Develop Project Charter In diesem Prozess wird ein Dokument zur Legitimierung und Erfassung der initialen Anforderungen des Projekts erstellt. Identify Stakeholders In diesem Prozess werden alle vom Projekt betroffen Personen und Organisationen identifizieren Planning Process Group Develop Project Management Plan In diesem Prozess wird ein Plan erstellt, der vorgibt wie beim Planen, Ausführen, Überwachen und Steuern im Projekt vorgegangen werden soll. Collect Requirements In diesem Prozess werden die projektspezifischen Wünsche der Stakeholder erarbeitet und dokumentiert. Define Scope In diesem Prozess wird eine detaillierte Beschreibung des Projekts und des Produkts/Ergebnisses erarbeitet. Create WBS (Work Breakdown Structure) In diesem Prozess wird versucht das Projektergebnis in Komponenten zu zerteilen. Define Activities In diesem Prozess werden Arbeitspakete definiert. Sequence Activities In diesem Prozess werden die Abhängigkeiten zwischen den Arbeitspaketen identifiziert und dokumentiert. Estimate Activity Resources In diesem Prozess werden die benötigten Ressourcen für die Arbeitspakte identifiziert und quantifiziert. Estimate Activity Durations In diesem Prozess wird geschätzt wie viel Zeit nötig ist um ein Arbeitspaket mit den zugeordneten Ressourcen abzuschließen. Develop Schedule In diesem Prozess wird ein Projektablaufplan auf Basis der Arbeitspakete unter Berücksichtigung ihrer Abhängigkeiten und Dauer erstellt. Estimate Costs In diesem Prozess werden die Kosten für die Arbeitspakete geschätzt. Determine Budget In diesem Prozess werden die vermuteten Kosten der Arbeitspakete aufsummiert und von den Stakeholdern (insbesondere den Geldgebern) akzeptiert. Plan Quality In diesem Prozess werden die Qualitätsanforderungen an das Projekt und Produkt/Ergebnis identifiziert, dokumentiert und festgelegt wie dies nachgewiesen werden soll. Dirk Tamke, Patrick Rehder 22/34

24 4 : PMBOK Develop Human Resource Plan In diesem Prozess werden die Rollen, Verantwortlichkeiten, benötigten Fähigkeiten, Berichtsverhältnisse identifiziert und dokumentiert. Außerdem wird ein Fortbildungsplan erstellt. Plan Communications In diesem Prozess wird herausgefunden welche Informationen die verschiedenen Stakeholder benötigten, danach wird das Vorgehen beschrieben. Plan Risk Management In diesem Prozess wird festgelegt wie beim Risikomanagement vorgegangen werden soll. Identify Risks In diesem Prozess werden die projektbetreffenden Risiken identifiziert und dokumentiert. Perform Qualitative Risk Analysis In diesem Prozess werden die Risiken auf Basis von Eintrittswahrscheinlichkeit und Schaden priorisiert. Perform Quantitative Risk Analysis In diesem Prozess werden systematische Analyseverfahren (z.b. Fehlerbaumanalyse) für Risiken verwendet. Plan Risk Responses In diesem Prozess werden Maßnahmen zur Reduzierung von Risiken erarbeitet. Plan Procurements In diesem Prozess werden die Entscheidungen, das Vorgehen und mögliche Lieferanten zur Auftragsvergabe an Externe erfasst Executing Process Group Direct and Manage Project Execution In diesem Prozess wird die Ausführung der Arbeitspakete durch die Ressourcen koordiniert. Hierbei wird entsprechend des Projektmanagementplans vorgegangen. Perform Quality Assurance In diesem Prozess wird die Einhaltung der Qualitätsanforderungen überprüft und dokumentiert. Acquire Projekt Team In diesem Prozess wird sichergestellt, dass die benötigten Personen auch verfügbar sind. Develop Project Team In diesem Prozess wird versucht die Kompetenzen des Teams zu verbessern. Manage Project Team In diesem Prozess wird das Projektteam durch das Projekt begleitet und versucht Probleme/Störungen zu beheben. Distribute Information In diesem Prozess werden den Stakeholdern, wie geplant, Informationen zur Verfügung gestellt. Manage Stakeholder Expectations In diesem Prozess wird für ein gemeinsames Verständnis der Projektanforderungen zwischen Projektteam und Stakeholdern gesorgt, damit die Projektanforderungen den Bedürfnissen der Stakeholdern entsprechen und auch so verstanden werden. Conduct Procurements In diesem Prozess werden die geplanten Fremdleistungen beauftragt. Dirk Tamke, Patrick Rehder 23/34

25 4 : PMBOK Monitoring and Controlling Process Group Monitor and Control Project Work In diesem Prozess wird das Vorgehen im Projekt überwacht und reguliert. Perform Integrated Change Control In diesem Prozess werden alle Änderungen überwacht. Verify Scope In diesem Prozess werden fertiggestellte (Teil-)Projektergebnisse abgenommen. Control Scope In diesem Prozess wird der aktuelle Projektstatus überwacht. Control Schedule In diesem Prozess wird der Projektablaufplan überwacht. Control Costs In diesem Prozess werden die Projektkosten überwacht. Perform Quality Control In diesem Prozess wird die Durchführung von Qualitätssicherungsmaßnahmen überwacht. Report Performance In diesem Prozess wird der derzeitige Stand erfasst und eine Vorhersage getroffen. Monitor and Control Risks In diesem Prozess wird die Durchführung vom Risikomanagement überwacht. Administer Procurements In diesem Prozess werden die Leistungen der Lieferanten überwacht Closing Process Group Close Project or Phase In diesem Prozess werden alle nötigen Abschlussarbeiten durchgeführt. (z.b. Ressourcen freigeben, lessons learned dokumentieren, ) Close Procurements In diesem Prozess werden die Verträge mit Lieferanten auf Erfüllung validiert und alle relevanten Informationen archiviert. Dirk Tamke, Patrick Rehder 24/34

26 4 : PMBOK Wissensgebiete In der dritten Sektion werden die neun Wissensgebiete beschrieben 1 : Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communications Management Project Risk Management Project Procurement Management Mit 80% der Seiten macht die Sektion den größten Teil des PMBOK Guides aus und ist dementsprechend detailliert. Die Wissensgebiete bieten eine andere Perspektive auf die Projektmanagementprozesse, welche im Kapitel 4.3 bereits genannt wurden. Jedem Wissensgebiet sind die passenden Prozesse zugeordnet und finden dort eine ausführliche Beschreibung. Die folgenden Kapitel enthalten jeweils eine kurze Beschreibung des Wissensgebiets und eine Auflistung der zugehörigen Prozesse Project Integration Management Hinter dem Projekt Integration Management verbirgt sich das Herz des Projektmanagements. Die unter diesem Begriff vereinten Prozesse dienen zur Koordination der Arbeit im Projekt und sorgen für einen reibungslosen Ablauf. Das Project Integration Management enthält die folgenden Prozesse: Develop Project Charter Develop Project Management Plan Direct and Manage Project Execution Monitor and Control Project Work Perform Integrated Change Control Close Project or Phase Project Scope Management Im Project Scope Management sind die Prozesse zu finden, die bestimmen welche Anforderungen und Einschränkungen für das Projekt gelten und die Einhaltung dann überwachen. Die Ergebnisse im Project Scope Management werden als Basis für die folgenden Wissensgebieten verwendet. Das Project Scope Management enthält die folgenden Prozesse: Collect Requirements Define Scope Create WBS 1 Quelle: [3-1], Seite 67 Dirk Tamke, Patrick Rehder 25/34

27 4 : PMBOK Verify Scope Control Scope Project Time Management Beim Project Time Management werden die Arbeitspakete definiert, gemäß Abhängigkeiten in Verbindung gebracht, zeitlich geschätzt, Ressourcen zugeordnet, zeitlich geplant und letztlich überwacht. In diesem Wissensgebiet wird also versucht die zu erledigenden Arbeit in kleine, besser zu überblickende Stücke zu zerlegen, um diese dann schätzen und planen zu können. Das Project Time Management enthält die folgenden Prozesse: Define Activities Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule Control Schedule Project Cost Management Dieses Wissensgebiet betrachtet die Kostenseite des Projekts. Das Project Cost Management enthält die folgenden Prozesse: Estimate Costs Determine Budget Control Costs Project Quality Management Die Prozesse des Project Quality Managements bestimmen die Qualitätsanforderungen an das Projektergebnis und überprüfen deren Einhaltung. Das Project Quality Management enthält die folgenden Prozesse: Plan Quality Perform Quality Assurance Perform Quality Control Project Human Resource Management Ein Projekt wird stets durch ein Projektteam bewältigt. Dieses Wissensgebiet beschäftigt sich mit den Mitgliedern des Projektteams. Das Project Human Resource Management enthält die folgenden Prozesse: Develop Human Resource Plan Acquire Project Team Develop Project Team Manage Project Team Dirk Tamke, Patrick Rehder 26/34

28 4 : PMBOK Project Communications Management Über die Prozesse des Project Communications Management soll sichergestellt werden, dass alle Stakeholder berücksichtigt und informiert werden. Das Project Communications Management enthält die folgenden Prozesse: Identify Stakeholders Plan Communications Distribute Information Manage Stakeholder Expectations Report Performance Project Risk Management Jedes Projekt ist Risiken unterworfen. Die Prozesse des Project Risk Managements versuchen diese Risiken zu identifizieren, zu bewerten und Maßnahmen zu finden. Das Project Risk Management enthält die folgenden Prozesse: Plan Risk Management Identify Risks Perform Qualitative Risk Management Perform Quantitive Risk Management Plan Risk Responses Monitor and Control Project Risks Project Procurement Management Insofern das Projekt externe Produkte oder Dienstleistungen benötigt, werden diese in den Prozessen des Project Procurement Managents geplant, veranlasst und überwacht. Das Project Procurement Management enthält die folgenden Prozesse: Plan Procurements Conduct Procurements Administer Procurements Close Procurements Dirk Tamke, Patrick Rehder 27/34

29 4 : PMBOK Qualifizierungsmodell Das Project Management Institute bietet die folgenden Zertifizierungen an 1 : Certified Associate in Project Management (CAPM) Grundlagen für Projekte (für Projektteilnehmer) Project Management Professional (PMP) most important industry-recognized certification for project managers 2 Program Management Professional (PgMP) Program Manager = jmd. der Projekte definiert, Projekt Manager zuweist, der eine Projekt- Gruppe (program) betreut PMI Agile Certified Practitioner (PMI-ACP) agile Ansätze zum Projekt Management PMI Risk Management Professional (PMI-RMP) Risikomanagement (siehe entsprechende Ausarbeitung) PMI Scheduling Professional (PMI-SP) Ablauf- und Terminplanung bzw. -überwachung von Projekten Zu jeder Zertifizierung gibt es ein offizielles Handbuch das den Rahmen der Zertifizierung beschreibt. Im Folgenden soll die Zertifizierung zum Project Management Professional weiter erläutert werden, da sie die Inhalte von PMBOK in Gänze abdeckt Project Management Professional (PMP) Laut Project Management Institute handelt es sich bei der Zertifizierung zum Project Management Professional um die wichtigste durch die Industrie anerkannte Zertifizierung für Projektmanager. 2 Dies wird beispielsweise durch Kayenta 3 : Damit ist das PMP-Zertifikat das weltweit erfolgreichste Prüfsiegel für erfahrene Projektmanager/-leiter. und durch frontline consulting 4 : Die PMP- Zertifizierung nach PMI ist die international am meisten verbreitete und akzeptierte Zertifizierung für Projektmanager. bekräftigt. Derzeit gibt es weltweit über zertifizierte Project Management Professionals. 5 Zur Teilnahme an die Zertifizierung müssen die folgenden Bedingungen erfüllt werden 6 : Teilnahme an einer mindestens 35 Stunden umfassenden Schulung Bachelor (four-year degree), dann o mindestens 3 Jahre Erfahrung im Projektmanagement o mindestens Stunden Erfahrung im Projektmanagement Abitur (secondary diploma), dann o mindestens 5 Jahre Erfahrung im Projektmanagement o mindestens Stunden Erfahrung im Projektmanagement Die Erfüllung der Bedingungen wird stichprobenartige überprüft. 1 Quelle: [3-7] 2 Quelle: [3-8] 3 Quelle: [3-9] 4 Quelle: [3-10] 5 Quelle: [3-2], Seite 9 6 Quelle: [3-2], Seite 15 Dirk Tamke, Patrick Rehder 28/34

30 4 : PMBOK Des Weiteren muss der Code of Ethics und Professional Conduct 1 als Voraussetzung der Zertifizierung gelesen und mittels Unterschrift akzeptiert werden. In dem sechsseitigen Dokument werden vier zu verfolgende Eigenschaften definiert: responsibility (Verantwortlichkeit) respect (Respekt) honesty (Ehrlichkeit) fairness (Gerechtigkeit) Für Mitglieder beim Project Management Institute beträgt die Prüfungsgebühr 340 Euro. Nicht- Mitglieder müssen 465 Euro bezahlen, wobei eine Jahresmitgliedschaft für etwa 100 Euro geschlossen werden kann. 2 Die Zertifizierung hat eine Gültigkeit von 3 Jahren. Dies begründet sich darauf, dass Zertifizierte an einer stetigen Weiterentwicklung interessiert sein sollen und somit die Qualität der Zertifizierung gewährleistet werden kann. Während der 3 Jahre müssen zur Verlängerung im Rahmen des Continuing Certification Requirements Programs mindestens 60 PDUs (professional development units) angesammelt werden. Die Abbildung 11 zeigt den dreijährigen Zyklus und eine Suspension Period. Sollte man die 60 PDUs nicht im Laufe der Suspension Period erreichen muss die Zertifizierung komplett neu abgelegt werden. PDUs können beispielsweise durch Kurse, aber auch die nachweisliche Arbeit als Projektmanager erlangt werden. 3 Abbildung 11 Projekt Management Professional: CCR Cycle and Suspension Period 4 1 Quelle: [3-11] 2 Quelle: [3-2], Seite 15 3 Quelle: [3-12] 4 Quelle: [3-12], Seite 35 Dirk Tamke, Patrick Rehder 29/34