IPMA(R) Level D - Report E-Book

Maik Uhlig

• Herausgeber: BoD - Books on Demand
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2025

Seitenzahl: 260

Beschreibung

Das Handbuch erklärt alle Themen des Reports nach dem neuen Leitfaden (September 2024). Mit vielen Beispielen und Tipps für die Praxis und Bezug auf die alternative Darstellung in hybriden Reports.

Leseprobe

Inhalt

0  Einleitung, Vorwort und Danke in Kurzform

1  Management Zusammenfassung

1.1  Angaben zum Projekt

1.1.1  Big Picture

1.1.2  Project Canvas

1.2  Eigene Position im Projekt

1.2.1  Beispiel Management Zusammenfassung

2  Strategie 04.03.01

2.1  Beschreibung des Business Case zum Projekt

2.2  Nennung der kritischen Erfolgsfaktoren des Projekts

3  Governance, Strukturen und Prozesse 04.03.02

3.1  Begründung, warum es sich bei dem Vorhaben um ein Projekt handelt.

3.2  Nennung der Projektart des Projektes und Begründung der Einordnung

3.3  Nennung und Begründung der Klassifizierung des Projekts aus Sicht der Organisation

3.4  Nennung der Strukturen der Organisation

3.4.1  Der Lenkungsausschuss: (LA)

3.4.2  Projektoffice (PO)

3.4.3  Projektmanagementoffice (PMO)

4  Anforderungen und Ziele 04.05.02

4.1  Steckbrief

4.2  Ziele

4.2.1  Beispiel Ziele

4.3  Zielkonflikt

4.3.1  Zielidentität

4.3.2  Zielkomplementarität

4.3.3  Zielneutralität

4.3.4  Zielkonkurrenz

4.3.5  Zielantinomie

5  Stakeholder 04.05.12

5.1  Projektumfeld

5.2  Schnittstellen

5.2.1  Ansprechpartner:

5.2.2  Auswirkung auf andere PM-Methoden:

5.3  Stakeholder-Portfolio

5.4  Stakeholder-Interessen

6  Macht und Interessen 04.03.04

6.1  Stakeholder-Bewertung

6.1.1  Macht durch Belohnung (REWARD POWER)

6.1.2  Macht durch Zwang (COERCIVE POWER)

6.1.3  Macht durch Legitimation (LEGITIMATE POWER)

6.1.4  Macht durch Identifikation (REFERENT POWER)

6.1.5  Macht durch Wissen (EXPERT POWER)

6.1.6  Macht durch Informationsvorsprung (INFORMATIONAL POWER)

6.2  Machtpromotoren

7  Chancen und Risiken 04.05.11

7.1  Projektrisiken

7.2  Maßnahmen

7.3  Chance

8  Projektdesign 04.05.01

8.1  Erfolgskriterien

8.1.1  Anwendungserfolg (Punkte 1-4)

8.1.2  Abwicklungserfolg (Punkt 5)

8.2  Vorgehensweise

8.2.1  Planbasiert

8.2.2  Hybrid

9  Organisation, Information und Dokumentation 04.05.05

9.1  Projektorganisationsform

9.1.1  Auswahl und Begründung

9.1.2  Visualisierung

9.1.3  Agile Visualisierung

9.2  Rollen

9.3  Kommunikationsmatrix

10  Ablauf und Termine 04.05.04 Teil 1

10.1  Phasenplan

10.1.1  Wasserfallmodell

10.1.2  V-Modell

10.1.3  Produktionsentstehungsprozess (PEP)

10.1.4  Eigene Vorgehensweise:

10.1.5  Beispiel Phasenplan

10.1.6  Beispiel hybride Darstellung

10.2  Phasenbeschreibung

11  Leistungsumfang und Lieferobjekte 04.05.13

11.1  Projektstrukturplan / Product-Backlog

11.1.1  Gliederungsformen

11.1.2  Tipp

11.1.3  Arbeitspakete

11.1.4  Beispiel Projektstrukturplan

11.1.5  Hybrider Projektstrukturplan und Product Backlog

11.2  Gliederungsform / Detaillierung

11.2.1  Beispiel Funktionsorientierte Gliederung

11.2.2  Beispiel Objektorientierte Gliederung

11.2.3  Beispiel Geografische Gliederung

11.2.4  Beispiel Phasenorientierte Gliederung

11.2.5  Beispiel für hybride Begründung

11.3  Arbeitspaket / User-Stories

11.3.1  Forschrittsgradmessung Methoden

11.3.2  Beispiel Arbeitspaket

11.3.3  Beispiel Userstories

12  Ablauf und Termine 04.05.04 Teil 2

12.1  Ablaufplan

12.1.1  Beispiel Ablaufplan

12.1.2  Beispiel hybrider Ablaufplan

13  Ressourcen 04.05.08

13.1  Personalressourcen

13.1.1  Beispiel Personalressourcen

13.2  Sachmittel

13.2.1  Beispiel Sachmittel Tabelle

13.3  Ressourcenganglinie

13.3.1  Beispiel Ressourcenganglinie

14  Kosten und Finanzierung 04.05.07

14.1  Aufwandsermittlung

14.1.1  Methoden

14.1.2  Aufwandsübersicht

14.1.3  Beispiel Aufwandsermittlung

14.1.4  Hybride Aufwandsermittlung

14.2  Kostenganglinie

14.3  Kostensummenlinie

15  Planung und Steuerung 04.05.10

15.1  Statusbericht / Fortschrittsbericht

15.1.1  Beispiel Statusbericht:

15.1.2  Hybrides Beispiel Statusbericht

16  Persönliche Kommunikation 04.04.03

16.1  Kommunikationsmodell

16.1.1  Nachrichtenquadrat (F. Schulz v. Thun)

16.1.2  Sender-Empänger-Modell (Shanon & Weaver)

16.1.3  Eisbergmodell (angelehnt an S. Freud)

16.1.4  Axiom-Modell (P. Watzlawick)

16.1.5  Beispiel Kommunikationsmodell

17  Erklärung betreffend die eigenständige Ausführung dieser Arbeit

18  Übersicht der verwendeten Abkürzungen

19  Glossar

20  Anlagen und Abbildungen

21  Tabellenverzeichnis

22  Abbildungsverzeichnis

0 Einleitung, Vorwort und Danke in Kurzform

Auf dem Buchrücken habe ich die “längst fällige” Neustrukturierung erwähnt, die ich jetzt hier in diesem Buch erörtern und fachlich hinterlegen darf. Es ist eine Befreiung von einem Konzept, das undurchsichtig und schwierig umzusetzen war. Mit der neuen Ausrichtung wird jetzt eine klare Übersicht gegeben, wie bewertet wird und wie viel Anteil die einzelnen Kompetenzelemente am Gesamtreport haben. Das sind nicht zu unterschätzende Vorteile.

Außerdem wurden in der alten Variante hybride Ansätze, die es aber schon als ipma®-hybrid-Zertifizierung gibt, nicht berücksichtigt. Dies ist nun der Fall und daher ist dieses Buch auch für mich teilweise Neuland. Nicht im Themenbereich selbst, da ich nicht nur ein Buch über Agilität geschrieben habe, sondern über die folgenden agilen Zertifikate verfüge:

Aber in der Kombination des Reports ist es für mich auch eine neue Herausforderung gewesen. Die erste Neuerung ist also die Möglichkeit, auch agile Prozesse mit einbinden zu können und die ersten hybriden Reports aus meinem Unterricht wurden schon erfolgreich erstellt.

Die zweite Neuerung ist die neue Reihenfolge im Report selbst, die ich als sehr sinnvoll erachte, andererseits gibt es Verschiebungen, also Kompetenzelemente, die vorher im Report waren, werden jetzt in der schriftlichen Prüfung abgefragt und zwangsläufig wandern diese Elemente, die vorher schriftlich abgefragt wurden, dann wiederum in den Report. Besonders die Verschiebung des Kompetenzelementes Qualität (4.5.6) ist für mich eine erhebliche Erleichterung, war es doch immer ein zwanghaftes Reinpressen von Abnahmekriterien in eine Tabelle, nachdem Anforderungen gesetzt wurden, diese dann in operationalisierte Ziele umgewandelt wurden und dann wieder unter dem neuen Gesichtspunkt der Lieferobjekte abgenommen werden mussten. Alles verstanden? Muss nicht, das fällt nun weg.

In der folgenden Übersicht ist das jetzt erkennbar:

Abbildung 1 Übersicht Kompetenzelemente

Im Report sind drei Elemente aus dem Kontextbereich Perspective hinzugekommen, der vorher gar nicht vertreten waren. Das hat zur Folge, dass diese Fragen nicht mehr in der schriftlichen Prüfung auftreten:

Strategie (4.3.1)

Hier gab es Fragen zu Analysen, die die Rentabilität eines Projektes betreffen oder beispielsweise Kritische Erfolgsfaktoren.

Governance, Strukturen und Prozesse (4.3.2)

Hier wurden erfahrungsgemäß mehr Fragen gestellt, wie z.B. Fragen zum Projekt-Management-Office, dem Lenkungsausschus, Programm vs. Portfolio, der Art von Projekten (Investition, Forschung&Entwicklung, Organisation), aber auch zur Theorie, wann ein Projekt ein Projekt ist.

Macht und Interessen (4.3.4)

Hier ging es in erster Linie um Stakeholder und das Projektumfeld.

Für den neuen Report müssen sich die neuen Prüflinge nun aber mit neuen Theorien vertraut machen, die in der schriftlichen Prüfung zusätzlich abgefragt werden:

Selbstreflexion und Selbstmanagement (4.4.1)

Vielseitigkeit (4.4.8)

Qualität (4.5.6)

Zusammenfassend bin ich der Meinung, dass die schriftliche Prüfung dadurch etwas schwieriger wird, aber der Report wiederum erheblich leichter, da die Themen in Ruhe ausgesucht werden können und zusätzliche Vereinfachungen hinzukommen, weil es jetzt eine Einsicht in die Bewertung und detailliertere Vorgaben gibt.

Und das Beste: Es gibt jetzt eine Word-Vorlage, die zum Download angeboten wird. Einfacher geht nicht!

Und genau diese Vorlage wird dieses Buch Stück für Stück behandeln. Ich werde jedes einzelne Kompetenzelement abarbeiten, die Anforderungen an den Report selbst erklären, das notwendige Hintergrundwissen vermitteln und dann Beispiele vorschlagen, um praktische Ideen vermitteln zu können, die dann wiederum als Gedankenanstoß für den eigenen Report dienen sollen.

Ein immer wiederkehrendes Problem im Unterricht ist und war der Umgang mit der notwendigen Software Word und einem PM-Programm für die Darstellung eines Gantt-Diagrammes. Dazu werde ich mich im Laufe des Buches äußern und entsprechende Hinweise geben, ausführliche Video-Anleitungen sind unter https://uhligland.de zu finden.

Und jetzt noch ein wichtiger Hinweis: Der Report ist ohne fremde Hilfe eigenständig anzufertigen. Bücher, wie dieses, verstehen sich als Hilfestellung und sollen dazu führen, dass der Report eigenständig erarbeitet und erstellt wird.

Tabellen zu kopieren und dann die Inhalte anzupassen mag zwar schnell gehen, aber sie verfehlen die Aufgabenstellung, für das eigene Projekt einen eigenen Report zu erstellen. Ich bitte daher um Beachtung, dass dieses Buch nicht als 1:1-Vorlage genutzt werden sollte. Wenn ich als Assessor immer wieder dieselben Tabellen und denselben Aufbau vorgelegt bekäme, könnte ich auf den Gedanken kommen, dass der Report nicht ernsthaft selbst erstellt wurde…

Meine Beispiele sind Gedankenanstöße und ich freue mich, wenn sie dabei helfen, den eigenen erfolgreichen Report zu erstellen. Jedes Projekt ist anders (sonst wäre es kein Projekt) und daher darf auch jeder Report anders sein.

Und fühlen Sie sich eingeladen, jederzeit unter https://uhligland.de zu schauen, ob es Neuigkeiten gibt, die diese Buch ergänzen.

Außerdem werden dort alle im Buch genannten Internetlinks direkt zur Verfügung gestellt, was die Navigation einfacher macht.

Maik Uhlig

Ungarn, 2024

Hinweis zur aktualisierten Auflage:

Es ist eher selten, gleich im ersten Jahr eine aktualisierte Auflage zu veröffentlichen, jedoch gab es so viele konstruktive Rückmeldungen und neue Erkenntnisse bezüglich der Prüfungsrelevanz bestimmter Inhalte, dass ich diese so schnell wie möglich umsetzen und zur Verfügung stellen wollte.

Hier sei auch noch einmal meinen Kursen ein Dank geschuldet, die unermüdlich Fragen stellen, die dann wiederum des öfteren zu neuen Erkenntnissen führen, die auch hier mit eingearbeitet wurden.

Vielen Dank!

Maik Uhlig

Ungarn, 2024

Formale Anforderungen

Abbildung 2 Z01_Leitfaden Allgemein / 13 / 01.09.2024

Diese Anforderungen sind einfach umzusetzen, da es von der Zertifizierungsstelle eine Vorlage zum Download gibt.

https://www.pm-zert.de/fileadmin/pm_zert_upload/Zertifizierung/Projektmanagement/Ab_September_2024/Z01D_PM_Report-Template.docx

Diese Vorlage bringt schon die wichtigsten Einstellungen mit sich, wenn auch der letzte Punkt (Seitenrand oben und unten von jeweils ca. 2 cm) sehr flexibel voreingestellt wurde. Oben: 2,5 cm und unten: 3,0 cm…

Nun denn, bis jetzt hat noch niemand nachgemessen. Also, wir nehmen die Vorlage so wie sie ist. Sollten wir am Ende noch Platzprobleme haben, also auf Biegen und Brechen nicht auf 25 Seiten reduzieren können, wäre hier eine Stellschraube. Rand auf 2 cm reduzieren, das kann eine Menge bewirken.

Unter

https://www.pm-zert.de/anmeldung/anmeldeunterlagen

stehen noch weitere Dateien zum Download zur Verfügung.

Leitfaden Zertifizierung Level D - V19 (Stand 02.09.2024)

Leitfaden Allgemein - V13 (Stand 02.09.2024)

Leitfaden Online-Prüfungen - V07 (Stand 02.09.2024)

Report Template Level D Projektmanagement - V03 (Stand 04.09.2024)

Taxonomie Projektmanagement - V02 (Stand 02.09.2024)

Leistungsnachweis zur Zertifizierungsanmeldung - V02R08 (Stand 02.09.2024)

Gebühren ab 01.09.2023

Rechtliche Erklärung des Zertifikanten - V01 (Stand 02.09.2024)

Es lohnt ein Blick in die einzelnen Dokumente. Wichtig ist hierbei die Excel-Datei, da diese für die Anmeldung selbst genutzt werden muss. Auch das letzte Dokument sollte beachtet werden, es ist neu hinzugekommen und beinhaltet eine rechtliche Erklärung, deren Bestätigung Voraussetzung für die Zulassung zur Prüfung ist.

Einige Infos noch zur Word-Vorlage für den Report (Report Template):

Tabellen dürfen über mehrere Seiten (hochkant oder quer) dargestellt werden. Bedingung ist, dass auf jeder Seite die Tabellenüberschrift enthalten ist.

Das ist eine verständliche Forderung für die Lesbarkeit des Reports. Auch hier gibt es einen Hinweis unter uhligland.de, wie das automatisiert werden kann.

Abbildungen in hochkant (Portrait) oder quer (Landscape) müssen auf einer Seite dargestellt werden. Sie dürfen händisch erstellt sein.

OK, das ist eine hilfreiche Vorgabe, aber meistens ist es einfacher, in Paint oder direkt über Formen oder SmartArt ein Bild zu erstellen und es dann einzufügen, als es zu malen, zu scannen, zurechtzuschneiden und dann einzufügen. Sei es drum, es ist erlaubt und wer möchte, kann es nutzen, solange die Abbildung auf einer Seite dargestellt wird.

max. 25 Seiten netto Text

Anhang - max. 15 Seiten Bilder, Grafiken, etc.

Das ist eine quantitative Vorgabe, die wir einzuhalten haben, wie auch immer, da gibt es keinen Spielraum, aber es ermöglicht jetzt eine Vorgehensweise, wenn wir wirklich zu viel Text haben. Dann könnte im Text Bezug auf den Anhang genommen werden. Das ist eine Möglichkeit, wenn es einfach nicht möglich ist, die empfohlene Seitenzahl einzuhalten. Aber, und das habe ich in den letzten 100 Reports, die ich gesehen habe, immer wieder feststellen können: Die 25 Seiten reichen aus. Die Tendenz geht eher auf weniger.

Inhaltsverzeichnis, Abkürzungsverzeichnis, Tabellenverzeichnis und Glossar werden nicht zu den Text-Seiten gerechnet.

Das ist beruhigend, beinhaltet aber auch die Info, dass wir eben diese Verzeichnisse auch benötigen. Dazu kommt ein Anhangsverzeichnis, wenn wir mit ausgewiesenen Anhängen arbeiten. Die o.g. Verzeichnisse sind kein Anhang.

Das war es auch schon, jetzt geht es endlich los!

Abschnitt 1: Kontext des Projektes

1 Management Zusammenfassung

In diesem ersten Abschnitt geht es nur um den Kontext selbst und die Einordnung des Projektes.

Für die folgenden Anforderungen wird insgesamt eine Seite als Maximum vorgegeben. Das ist eine problemlose Einschränkung, eine Seite reicht völlig aus. Dabe ist zu beachten, dass der Erfüllungsgrad mit „Formal erforderlich“ angegeben wird, also „nur“ der Check, ob es vorhanden ist, es wird nicht bewertet.

1.1 Angaben zum Projekt

Folgende Angaben müssen gemacht werden:

Real / Fiktiv

Hat es sich um ein reales oder fiktives Projekt gehandelt? Diese Information hat überhaupt keine Auswirkung auf den Report selbst und kann daher ganz offen und ehrlich hinterlegt werden.

Abgeschlossen / Laufend / Geplant

Hier wird es schon etwas kniffliger, weil es in 15.1 um die Darstellung eines im Projekt angewendeten Kommunikationsmodells geht… Wenn es geplant ist, kann es dieses angewendete Modell ja gar nicht geben!

Auch der unter 14.1. geforderte Statusbericht über den Fortschritt eines gewählten Arbeitspaketes oder alternativ der erstellten Userstory kann noch kein Ergebnis haben!

Hier müsste dann in diesen Abschnitten klargestellt werden, dass es sich um eine Vorausschau handelt.

Mein Tipp: Wenn das Projekt fiktiv ist, was meistens der Fall sein sollte, wird das Projekt fiktiv beendet sein, wenn wir den Report schreiben, das ist die einfachste Lösung.

Liegt eine Vertraulichkeitserklärung vor und sind daher Eigennamen anonymisiert?

Viele Organisationen erlauben die Verwendung von Namen, aber es gibt in unserem Report auch Auftraggeber und Stakeholder, die außerhalb unserer Organisation tätig sind. Von denen haben wir aber im Normalfall keine Freigabe für die Nennung ihrer Klarnamen. Daher sollte der Form halber hier eine entsprechende Erklärung abgegeben werden, dass eine Vertraulichkeitserklärung vorliegt und daher anonymisierte Namen verwendet werden. Auch in fiktiven Projekten! Wir gehen ja davon aus, dass das fiktive Projekt ein „echtes“ Projekt widerspiegelt, und da könnte eben auch diese Vertraulichkeitserklärung vorliegen. Es sollte nur darauf hingewiesen werden, dass die Vertraulichkeitserklärung fiktiv vorliegt.

Mein Tipp: Für die anonymisierten Namen denke ich an Freunde und Bekannte, deren Namen ich einfach leicht abwandle, mit denen ich aber eine typische Eigenschaft verbinde oder denen ich einfach in Gedanken die Aufgabe übertrage, die auch meine Stakeholder im Report haben. Das vereinfacht die Verwendung und ist eine große Hilfe bei der Stakeholderanalyse. Wenn meine Tante im Elisabeth-Krankenhaus im Empfang arbeitet und total lieb ist und immer gern hilft, dann nenne ich die Wareneingangs-Verantwortliche einfach Elisabeth Gern und kann sie als Stakeholderin gut einschätzen.

Zusätzlich kann ein Big Picture als Grafik erstellt werden.

Bei Scrum gibt es den Ansatz, die nicht getane Arbeit zu maximieren. Wenn die Angaben zum Projekt als Erfüllungsgrad nur bewerten, ob es vorhanden ist und ich mein Big Picture „zusätzlich erstellen darf“, dann ist es auch ohne Konsequenzen, wenn ich es nicht erstelle…

Dennoch ist es eine Möglichkeit und dieses Handbuch wäre kein Handbuch, wenn das Thema „Big Picture“ außer Acht gelassen werden würde.

1.1.1 Big Picture

„Ein Bild sagt mehr als 1000 Worte“

Wenn wir es schaffen, unser Projekt mit allen wichtigen Informationen (Aufgaben, Leistungen, Schnittstellen, Lieferobjekte, Erfolgskriterien, Risiken, Chancen, Stakeholder, …) als Übersicht darzustellen, hilft es allen Beteiligten, den Fokus auf die Gesamtheit zu bewahren. Dafür gibt es verschiedene Ansätze.

Das „Handbuch für Praxis und Weiterbildung im Projektmanagement“1 versteht unter einem Big Picture die plakative Visualisierung der wichtigsten Aspekte und Zusammenhänge, die eine gemeinsame Sicht verschafft, eine Diskussionsgrundlage bietet, das Verständnis aller Beteiligten vereint und unterschiedliche Sichtweisen, Prioritäten und Perspektiven offensichtlich macht. Außerdem ist es ein Überblick, der erkennbar macht, welche Informationen noch fehlen.

In dem höchst interessanten Buch „Projektmanagement am Rande des Chaos“2 verweisen die Autoren auf einen weiteren Vorteil eines Big Pictures, da sie empfehlen, Kommunikation „am Big Picture auszurichten“. Das ist tatsächlich eine gute Strategie, da alle bei einer Kommunikation, die bekanntlich auf mehreren Ebenen stattfindet, eine gemeinsam anerkannte sichtbare Ebene als Grundlage und Fokus nutzen.

Im Klassiker „Projektmanagement“ von Patzak & Rattay3 wird auch in der 7. Auflage aus dem Jahr 2018 das Big Picture noch als „Trend“ bzw. „neue Entwicklung“ bezeichnet und findet tatsächlich erst spät im Kapitel über hybrides Projektmanagement auf Seite 675 Beachtung.

Per se sind also sämtliche Darstellungen, die projektbezogene Informationen auf einen Blick liefern, ein Big Picture. Im Report werden wir einen Projektsteckbrief, einen Ablaufplan, einen Phasenplan und einen grafischen Projektstrukturplan in Baumstruktur oder alternativ einen Releaseplan, ein Product-Backlog oder ein KANBAN-Board erstellen, das sind alles Big Pictures. Hier ist eher ein grober Überblick gemeint, dafür gibt es viele Möglichkeiten, von denen ich beispielhaft eines ausgewählt habe, das sowohl in klassischen als auch in hybriden Projekten voll zum Einsatz kommen kann.

1.1.2 Project Canvas

In seinem Buch „THE MAKER PROJECT CANVAS“4 beschreibt John van Saders sehr ausführlich die Möglichkeiten, die sich mit der Darstellung eines Canvas ergeben. Für unser Projekt können wir uns auf die wesentlichen Merkmale eines Projekt-Canvas konzentrieren, das beispielsweise in einer interessanten Reihe „Guide +100 Business Model Templates“5 unter der einfachen Betitelung „Project Canvas“ ausführlich erörtert wird. Zusammenfassend ist dieses Modell eine Visualisierung der Schlüsselelemente eines Projektes. Es gibt viele Varianten, wichtig dabei ist der Unterschied zwischen dem Project-Canvas, also einer Visualisierung des Projektes und dem Busines-Modell-Canvas, welches das Geschäftsmodell eines Unternehmens darstellt. Grundsätzlich haben sich im Project Canvas die folgenden 11 Schlüsselelemente durchgesetzt:

Projektkontext

Zweck des Projekts: Was ist das Ziel des Projekts? Was soll erreicht werden?

Budget: Wie hoch sind die zu erwartenden Gesamtkosten des Projekts? Wie werden die Kosten aufgeschlüsselt?

Team: Wer sind die Mitglieder des Projektteams? Welche Rollen haben sie?

Umfeld: In welchem Umfeld wird das Projekt durchgeführt? Welche internen und externen Faktoren können das Projekt beeinflussen?

Projektplanung

Etappenziele: Welche Meilensteine müssen erreicht werden, um das Projekt erfolgreich abzuschließen?

Qualität: Welche Qualitätsstandards müssen erfüllt sein?

Ergebnis: Was ist das konkrete Ergebnis des Projekts? Was wird geliefert?

Projektdurchführung

Kunde: Wer ist der Zielkunde des Projekts? Was sind ihre Bedürfnisse und Erwartungen?

Ressourcen: Welche Ressourcen werden benötigt, um das Projekt durchzuführen?

Zeit: Wie lange wird das Projekt dauern? Wann sind die wichtigsten Termine?

Risiken und Chancen: Welche Risiken können das Projekt gefährden? Welche Chancen können genutzt werden?

Am Beispiel einer Pizzeria (ich habe sie einmal Vitapizza getauft), die nur gesunde und biologische Zutaten verwendet, könnte ein Project-Canvas-Modell so aussehen:

Abbildung 3 Big Picture Beispiel

Hier stehen alle wichtigen Informationen auf einem Blick gruppiert zur Verfügung. Das erhöht den Fokus und kann in jeder Sitzung als Diskussionsgrundlage verwendet werden, um das Gesamt-Konstrukt nicht aus den Augen zu verlieren.

Bei allen Informationen im Big Picture handelt es sich aber im Normalfall um Schätzungen aus dem Anfangsstadium des Projektes. Das bezieht sich auf alle Terminplanungen und besonders auf das Budget. Ein Budget ist eine Schätzung, die sich im Laufe des Projektes mit Sicherheit noch ändern wird. Es sind keine Projektkosten! Kosten fallen an und werden ermittelt. Wenn am Ende die Projektkosten innerhalb des angangs geplanten Projektbudgets bleiben, ist alles gut gelaufen.

Planbasiert/Klassisch/Traditionell oder Hybrid?

Es wird darauf hingewiesen, dass es möglich ist, einen hybriden Ansatz mit Scrum oder Kanban zu wählen. Es ist aber nicht möglich, einen rein agilen Ansatz für das gesamte Projekt zu wählen. Eine explizite Erklärung wird hier nicht verlangt, diese kommt in 8.2 noch.

Grundsätzlich ist es wichtig, zu wissen, dass auch bei einer hybriden Projektwahl der Report größtenteils klassisch erstellt werden kann! Die in den einzelnen Kompetenzelementen erwähnten agilen Darstellungen sind fast alle alternativ wählbar! Für diese wird auch im weiteren Verlauf immer ein Beispiel hinter dem Beispiel der klassischen Darstellung gegeben, aber keine ausführliche Erörterung agiler Vorgehensweisen. Wer also ein hybrides Projekt wählt, sollte auch Kenntnisse im agilen Projektmanagement mitbringen, ansonsten könnte der Report eine Tortur mit vielen Abzweigungen und immensem zeitlichem Aufwand werden, da gleich zwei Projektmanagementmethoden gelernt und dann noch zusammengebracht werden müssten.

In 10.2 muss beispielsweise zusätzlich zum Phasenplan mitgeteilt werden, in welchen Phasen agil gearbeitet wird.

In 14.2 und 14.3 wird darauf hingewiesen, dass in hybriden Projekten die Kostengang- und Kostensummenlinie im Falle der Darstellung über den gesamten Projektzeitraum auch die entsprechende hybride Termin- und Ablaufplanung als Grundlage dienen soll. Dennoch kann auch in hybriden Projekten ein Arbeitspaket gewählt werden, um das zu umgehen.

1.2 Eigene Position im Projekt

Beschreibung der eigenen Rolle im Projekt

In einem Projekt gibt es verschiedene Rollen, die dazu beitragen, dass das Projekt erfolgreich abgeschlossen wird. Die genaue Anzahl und Bezeichnungen der Rollen können je nach Art und Umfang des Projekts variieren, aber hier sind einige häufige Projektrollen:

1. Projektleitung: Sie ist für die Planung, Durchführung und Überwachung des gesamten Projekts verantwortlich. Sie koordiniert die Teammitglieder, Ressourcen und Aktivitäten, um sicherzustellen, dass das Projektziel erreicht wird.

2. Auftraggeber/Sponsor: Auftraggeber oder Sponsoren sind die Personen oder Gruppen, die das Projekt initiieren und die finanzielle Unterstützung und Zustimmung für das Projekt bieten. Sie haben oft die letzte Entscheidungsbefugnis.

3. Projektteam: Das Projektteam besteht aus Personen, die die verschiedenen Aufgaben und Aktivitäten im Rahmen des Projekts durchführen. Die Mitglieder können in unterschiedlichen Fachbereichen arbeiten, je nach den Anforderungen des Projekts.

4. Lenkungsausschuss (Steering Committee): Überwachung auf Strategieebene und Unterstützung zur Erreichnung der Projektziele. Oft durch den Auftraggeber geleitet mit weitreichender Entscheidungskompetenz. Weitere Vertretungen der Stakeholder sind im Lenkungsausschuss beteiligt. Der Lenkungsausschuss kann auch als Auftraggeber auftreten, was besonders in großen Organisationen der Fall ist. Der derzeitige CEO (Stand: 2024) der Mercedes-Benz Group AG ist Ola Källenius. Aber wird er als CEO mit mir einen Vertrag schließen? Eher nicht, dafür gibt es eine Hierarchie. Ein Lenkungsausschuss kann also ein Gremium sein, das vom CEO bevollmächtigt wurde, Projekte in Auftrag zu geben. Herr Källenius hingegen ist in der Regel nicht direkt in die tägliche Projektsteuerung involviert, da seine Rolle eher auf die Gesamtführung der Mercedes Benz AG und die übergeordneten strategischen Entscheidungen ausgerichtet ist.

5. Projektmanagement-Office (PMO) oder Projekt-Office (PO): Ähnlich wie im Lenkungsausschuss wird hier controlled und unterstützt, aber auf einer anderen Ebene. Während der Lenkungsausschuss das Bindeglied zum Management der Organisation darstellt, ist das PMO wiederum auf der Ebene der Projekte angesiedelt und unterstützt die Projektleitung. Es ist auch Empfänger der ständigen Dokumentation und hilft dabei, Hindernisse zu überwinden. Diese Tätigkeit würde einen Lenkungsausschuss überfordern. Dass das PMO im Sinne der Strategie handelt und selbst wiederum dem Lenkungsausschuss (wenn vorhanden) untergeordnet ist, versteht sich von selbst, da der Lenkungsausschuss das höchste Gremium ist. Ein PMO ist dauerhaft angelegt und für mehrere Projekte verantwortlich. Ein PO dagegen ist für ein Projekt verantwortlich und ist temporär nur während des Projektlebenszyklusses aktiv, danach wird es aufgelöst.

Das bedeutet nicht, dass große Firmen und große Projekte ein PMO haben und kleine nur ein PO, auch in großen Firmen kann es Sinn machen, ein PO einzurichten, wenn das Projekt einen hohen Stellenwert hat und das vorhandene PMO damit überlastet oder darauf nicht ausgerichtet wäre.

6. Stakeholder: Stakeholder sind Personen oder Gruppen, die vom Projekt betroffen sind oder Einfluss auf das Projekt haben. Dies können Kunden, Lieferanten, Mitarbeiter oder andere interessierte Parteien sein. Aber auch die vorher genannten Auftraggeber und Sponsoren gehören zur Gruppe der Stakeholder.

Es ist wichtig, dass die Verantwortlichkeiten und Aufgaben jeder Rolle klar definiert sind, um sicherzustellen, dass das Projekt effektiv und effizient abläuft. Je nach Projektart und -umfang können auch zusätzliche Rollen erforderlich sein.

In unserem Report werden wir aber mit diesen Rollen auskommen, die Frage ist nun am Ende nur: Welche Rolle haben wir eingenommen? Die Antwort ist denkbar einfach:

Projektleitung, da wir für die Planung, Durchführung und Überwachung des gesamten Projekts verantwortlich sind und die Teammitglieder, Ressourcen und Aktivitäten koordinieren, um sicherzustellen, dass das Projektziel erreicht wird.

Ist diese Rolle immer gleich? Natürlich nicht, die Rolle des Projektmanagers ist nicht dauerhaft belegt, sie wird temporär übernommen und ist daher nicht durch Stellenbezeichnungen oder klare Hierarchien geregelt. Projektmanager übernehmen dabei nicht eine bestimmte Rolle, sie sind hier tatsächlich breiter aufgestellt und sollten alle Rollen vertreten können. Projektbezogen wird dann aber die eine oder andere Rolle hauptsächlich in Anspruch genommen.

Das Projektmanagement-Handbuch6 listet die folgenden Funktionen der Projektleitung auf:

Koordinator – Wir organisieren Prozesse und achten auf die korrekten Abläufe. Außerdem behalten wir den Überblick in der Zusammenarbeit des Teams.

Moderator – Wir achten darauf, dass in Meetings und besonders in Brainstorming-Runden alle zu Wort kommen und Diskussionen objektiv und zielgerichtet verlaufen.

Berater – Wir beraten in Fachfragen und klären auftretende interpersonelle und teilweise auch intrapersonelle Probleme.

Konfliktmanager – Wenn Probleme nicht gelöst werden, entstehen Konflikte. Auch hier sind wir gefragt, diese Konflikte nicht eskalieren zu lassen und sie möglichst mit einer Win-Win-Situation zu beenden.

Repräsentant – Wir vertreten unser Team gegenüber der Organisation und stehen für deren Interessen ein.

Verhandlungsführer – Wenn es um Ressourcen geht, verhandeln wir für unser Team mit der Organisation, um bestmögliche Ausstattungen zu erhalten.

Darsteller – Wir sind das Gesicht des Teams. Wir stellen den Erfolg und die guten Ergebniss dar. Aber auch im umgekehrten Fall sind wir es, die Misserfolge erklären und dafür gerade stehen.

Von wem wurde diese Rolle zugewiesen?

Diese Antwort ist eng mit der Art des Projektes verbunden, die wir noch im Laufe sehr genau besprechen werden. In Kurzform aber gibt es folgende drei Möglichkeiten, wie das Projekt organisiert wird, was wiederum Auswirkungen hat, von wem wir normalerweise die Rolle zugewiesen bekommen.

Stabs-Projektorganisation

Autonome Projektorganisation

Matrix-Projektorganisation

1. Stabs-Projektorganisation

In dieser Organisation besitzt die Projektleitung keine disziplinarischen Weisungsbefugnisse und trifft keine Entscheidungen für Termine, Kosten oder Ergebnisse, verfügt also auch nicht über die fachliche Weisungsbefugnis. Ein solches Projekt ist für den Report eher ungewöhnlich, aber nicht auszuschließen. Auftraggeber könnte eine öffentliche Behörde sein.

2. Autonome Projektorganisation

Hier hat die Projektleitung die alleinige und vollständige Entscheidungsbefugnis (disziplinarisch und fachlich) und damit auch die volle Verantwortung für das Projekt. Auftraggeber ist meist eine externe Firma, also ein klassischer Auftrag.

3. Matrixprojektorganisation

Hier arbeitet unser Team (oder auch wir selbst) noch in anderen Abteilungen an anderen Aufgaben, unsere Befugnisse werden aufgeteilt und teilweise von Linienvorgesetzten der Stammorganisation übernommen. Unsere Entscheidungsbefugnisse und Verantwortung liegen zwischen der Stabs- und der autonomen Projektorganisation, wir haben zwar keine disziplinarische Entscheidungsbefugnis, wohl aber fachliche. Auftraggeber ist meist die Geschäftsführung oder eine andere über uns stehende Stelle innerhalb der eigenen Organisation, der wir angehören. Eventuell auch der Lenkungsausschuss.

Mein Tipp: Erst einmal angeben, dass uns Dagobert Duck diese Rolle höchstpersönlich zugewiesen hat. Im Laufe des Projektes wird diese Frage klarer und kann dann entsprechend nachgebessert werden. Aber nicht vergessen!

Damit wäre der erste Abschnitt komplett. Die Erstellung der verbindlichen Referenzen (Inhaltsverzeichnis, Abkürzungsverzeichnis, Tabellenverzeichnis, Glossar) werden in einem Video auf uhligland.de erklärt. In den Beispielen werden sie nicht extra mit abgebildet.

Der Leitfaden für Level D in der Version 19 sieht für den Abschnitt 1 höchstens eine Seite vor. Folgendes Beispiel wäre denkbar, wobei ich noch einmal darauf hinweisen möchte, dass dieser Abschnitt nicht bewertet wird! Er ist formal erforderlich, also weglassen können wir ihn nicht, aber er hat eben keinen Einfluss auf die Bewertung.

Andererseits ist es unser erstes Auftreten und der erste Eindruck sollte natürlich gut sein. Daher empfehle ich diesen Abschnitt genauso gewissenhaft zu bearbeiten wie die restlichen auch. Nur eben ohne Bewertungs-Stress.

Wird dieser Abschnitt aber weder ausreichend noch verständlich dargestellt, kann das dazu führen, dass der Report nicht angenommen wird!

1.2.1 Beispiel Management Zusammenfassung

1 Management Zusammenfassung

1.1 Angaben zum Projekt

Das von mir geleitete fiktive Projekt zur Erstellung eines Onlineshops für eine Pizzeria hat im zweiten Quartal 2023 stattgefunden und wurde zum Zeitpunkt der Erstellung dieses Reports schon abgeschlossen.

Da auch in dem fiktiven Projekt eine Vertraulichkeitserklärung vorgelegt und von mir unterschrieben wurde, habe ich alle Eigennamen anonymisiert. Beteiligte Firmenbezeichnungen wurden auch anonymisiert. Die einzige Klarnennung ist mein eigener Name.

Das Projekt wurde teils in eigenen, teils in den Räumlichkeiten der Auftraggeberin durchgeführt, um Abstimmungen mit den Geschäftsprozessen aktiv durchführen zu können. Es handelt sich dabei um eine Pizzeria mit langjähriger Erfahrung und zehn Filialen in der näheren Umgebung, die wiederum von einer Geschäftsführerin alleinverantwortlich geleitet wird.

1.2 Eigene Position im Projekt

Da ich für die Planung, Durchführung und Überwachung des gesamten Projekts verantwortlich war und außerdem die Teammitglieder, Ressourcen und Aktivitäten koordinieren sollte, um sicherzustellen, dass das Projektziel erreicht wird, wurde meine Rolle als „Projektleitung“ eingeordnet.

Meine Erfahrung im Bereich von Online-Shops waren Grundlage dieser Zuweisung und meiner Akzeptanz als Projektleiter.

Ich habe mich in dieser Rolle hauptsächlich als Koordinator gesehen.

Die Geschäftsinhaberin Samanta Fuchs hat mir diese Rolle mit den damit verbundenen Verantwortungen und Befugnissen per Projektauftrag zugewiesen.

Abschnitt 2: Methoden im Projekt

Der 2. Abschnitt bildet den Rest des Reports. Hier werden 14 Kompetenzelemente abgefragt und entschieden, ob diese als kompetent anerkannt werden. Die folgende Tabelle (nächste Seite) gibt eine Übersicht über die einzelnen Kompetenzelemente in der Reihenfolge, wie sie im Report behandelt werden, der Voraussetzung für das Bestehen des Kompetenzelementes und der empfohlenen Seitenzahl.

Bei der Seitenzahl kann variiert werden, wenn ein Kompetenzelement eine halbe Seite mehr hat und ein anderes eine halbe Seite weniger, ist am Ende alles in Ordnung. Es gibt aber weitere Anweisungen, die bindend sind:

Tabellen dürfen über mehrere Seiten (hochkant oder quer) dargestellt werden. Bedingung ist, dass auf jeder Seite die Tabellenüberschrift enthalten ist.

Grafiken in hochkant (Portrait) oder quer (Landscape) müssen auf einer Seite dargestellt werden. Sie dürfen händisch erstellt sein.

Und dann noch ein Hinweis, der zwar möglich aber eher umständlich ist, diesen umzusetzen. Warum sollte man sich die Arbeit komplett neu machen, wenn es eine anerkannte Vorlage gibt? In diesem Buch wird die Vorlage verwendet:

Zur Erstellung des Reports können Sie für jedes Zertifizierungslevel und zutreffende Domäne eine PM-ZERT-Vorlage von der PM-ZERT Webseite herunterladen. Es kann alternativ ein selbst erstelltes Dokument verwendet werden, wenn dieses der PM-ZERT-Vorlage entspricht.

Folgende inhaltliche Anforderungen müssen erfüllt werden:

Gliederungs-Nummer

ICB-Nummer

Kompetenz-element

Erfüllungs-grad

Seitenempfehlung

1

04.03.01

Strategie

1/2

1

2

04.03.02

Governance, Strukturen und Prozesse

2/4

1

3

04.05.02

Anforderungen und Ziele

/3

22

4

04.05.12

Stakeholder

2/4

3

5

04.03.04

Macht und Interessen

1/2

1

6

04.05.11

Chancen und Risiken

2/3

3

7

04.05.01

Projektdesign

1/2

1

8

04.05.05

Organisation, Information und Dokumentation

2/3

1,5

9

04.05.04

Ablauf und Termine

2/3

3

10

04.05.03

Leistungsumfang und Lieferobjekte

2/3

2,5

11

04.05.08

Ressourcen

2/3

1,5

12

04.05.07

Kosten und Finanzierung

2/3

1,5

13

04.05.10

Planung und Steuerung

1/1

1

14

04.04.03

Persönliche Kommunikation

1/1

0,5

Tabelle 1 Übersicht Kompetenzelemente, eigene Darstellung

Der Erfüllungsgrad beschreibt die Anzahl der Unterpunkte, die anerkannt werden müssen, um den gesamten Bereich als kompetent bewertet zu bekommen. Am Beispiel der ersten und dritten Kompetenz kann das erklärt werden.

Die erste Kompetenz besteht aus:

Abbildung 4 Übersicht Strategie

Kleiner Hinweis: Strategie hat die ICB-Nummer 4.3.1 – die Vorgabe enthält zum Zeitpunkt des Buchdrucks einen Fehler (4.5.1), den wir aber in unserem Report natürlich korrigieren. PMZert ist nicht perfekt .

Im Kapitel 2 muss also entweder 2.1 oder 2.2 vernünftig bearbeitet werden. Könnte ich also den Business Case weglassen, wenn ich mir sicher bin, dass 2.2 richtig beantwortet wurde? Nein, die Vorgaben werden klar im Leitfaden in einem extra blau gefärbten Kasten definiert: „Es müssen sämtliche Gliederungs-Nr. in der Tabelle 5: Report-Vorgaben bearbeitet werden!“ Die Gliederungsnummern sind das Pendant zu den Überschriften der zweiten Ebene (in diesem Fall: 2.1 und 2.2). Also wird jeder Punkt bearbeitet.

Auch im zweiten Beispiel ist es nachvollziehbar:

Abbildung 5 Übersicht Anforderungen und Ziele

Ein guter Steckbrief und ein logisch beschriebener Zielkonflikt würden dann ausreichen, wenn die genannten Ziele nicht den Anforderungen entsprechen. Spätestens hier wird klar, dass wir nicht einfach Punkte auslassen können. Ein Zielkonflikt bezieht sich auf die Ziele in 4.2 – wenn die fehlen, kann dieser Zielkonflikt gar nicht richtig bewertet werden.

Ein letzter Hinweis noch: Die einzelnen Kompetenzen werden nach Taxonomiestufen nach Bloom eingeordnet und bewertet. Für den Report sind die ersten vier von Bedeutung, die folgendes verlangen und im Leitfaden Allgemein erwähnt werden:

Kompetenzlevel 1 im Report beinhaltet die ersten zwei Stufen:

Stufe 1: Wissen [angeben, aufzählen, benennen, vervollständigen, wiedergeben, bezeichnen]

Stufe 2: Verstehen [begründen, einordnen, ordnen, unterscheiden, vergleichen, wiedergeben, beschreiben]

Kompetenzlevel 2